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3.  Abstract 


The  CAUSE  Resiliency  (West  Coast)  Experiment  jointly  sponsored  by  the  Department  of  Homeland  Security  (DHS) 
and  the  Defence  Research  and  Development  Canada  (DRDC)  was  conducted  in  June  2011.  Emergency 
management  communities  in  British  Columbia  and  Washington  State  participated  and  were  exposed  technologies  that 
have  recently  been  developed  or  are  nearing  operational  maturity.  This  report  provides  an  overview  of  the  experiment 
and  summary  of  the  findings  and  recommendations. 


Resume 

En  juin  2011,  des  organismes  de  gestion  des  urgences  operationnelles  en  Colombie-Britannique  et  dans  I’Etat  de 
Washington  ont  participe  au  projet  experimental  CAUSE  Resiliency  (cote  ouest),  parraine  conjointement  par  le 
departement  de  la  Securite  interieure  (DHS)  et  Recherche  et  developpement  pour  la  defense  Canada  (RDDC).  Ms  ont 
ete  exposes  a  des  technologies  recentes  ou  approchantes  la  maturite  operationnelle.  Ce  rapport  donne  un  apergu  de 
I’experience,  en  plus  de  resumer  les  resultats  et  les  recommandations. 
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4.  Executive  Summary 


4. 1  Project  Overview 

4.1.1  The  CAUSE  Resiliency  (West  Coast)  experiment  2011  was  one  of  a  series  of  projects  jointly  sponsored  by  the 
Department  of  Homeland  Security  (DHS)  and  the  Defence  Research  and  Development  Canada  (DRDC). 

4.1.2  The  project  was  designed  to  demonstrate  newly  operational  and  emerging  technologies  and  inform  future 
research  and  development.  One  key  goal  was  to  enhance  systems  interoperability  between  Canada  and  United 
States  partners. 

4.1.3  The  experiment  exposed  a  number  of  technologies  and  integration  options,  and  engaged  operational  emergency 
management  communities  in  British  Columbia  and  bordering  organizations  in  the  North  West  United  States. 

4.2  Organizations,  Scenario  and  Technology  Involved 

4.2.1  Five  different  organisations  and  sites  were  involved.  The  planning,  script  development  and  system  integrations 
were  conducted  over  a  period  of  seven  months,  and  execution  of  the  experiment  carried  out  on  21  June  2011.  Film 
crews  and  cameras  were  present  in  all  locations  to  capture  the  action  as  the  scripted  scenarios  were  played  out  to 
explore  the  technologies. 

4.2.2  The  operational  organisations  and  locations  involved  were:  Emergency  Management  British  Columbia  (EMBC), 
the  City  of  Richmond,  the  City  of  Vancouver,  Pacific  Northwest  National  Laboratory  (PNNL)  and  Washington  State 
Emergency  Management  Division. 

4.2.3  The  background  scenario  establishing  context  for  the  emergency  response  in  all  locations  was  a  major  Cascadian 
subduction  zone  earthquake  off  the  coast  of  Oregon  of  magnitude  9.0.  A  series  of  vignettes  were  developed  and 
scripted  based  on  various  time  slices  before  and  after  the  main  event. 

4.2.4  The  technologies  and  project  participant  involved  in  the  experiment  included  the  following  :  BCeMap 
(ESRI/GeoBC/Citizens  Services  BC),  HAZUS  (NRCan  /  FEMA)  ,  Ushahidi  (Simon  Fraser  University),  E  Team  (NC4), 
Fusionpoint  and  Smart  Client  (EmerGeo),  a  CAP/Atom  Scenario  Generator  (Planetworks),  the  Multi-Agency 
Situational  Awareness  System  (MASAS)  National  Implementation  Team  (NIT),  SA  Mapper  (PNNL)  MyStateUSA  and 
the  Integrated  Public  Alerting  and  Warning  System  (IPAWS  -  FEMA),  AMECom  truck  (Simon  Fraser  University). 

4.3  Summary  findings  and  Recommendations  •  overall  findings 

4.3.1  A  summary  of  the  findings  and  associated  recommendations  relating  to  both  the  overall  conduct  of  the  project  and 
each  technology  are  summarised  below: 


Overall 

Findings 

Recommendations 

-  The  experiment  enabled  a  number  of  integration 
options  to  be  explored  and  evaluated  with  minimal  cost. 
The  nature  of  the  sponsorship/funding  allowed  multiple 
provincial,  municipal,  vendor  and  research 
establishments  to  participate  and  interact  in  a  low  cost 
and  low  impact  manner. 

-  Continue  to  run  implementation  trials  and/or  pilots  to 
demonstrate  the  feasibility  and  benefits  of  using  emergent 
applications  and  tools  to  support  Emergency  Management. 

These  could  be  run  under  the  CAUSE  framework  and  involve 

US  participants  or  could  also  be  performed  Provincially  subject 
to  funding. 
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Overall 


Findings  Recommendations 

-  Creating  the  integrations  between  the  tools  in  the  -  A  small  amount  of  seed  funding  could  encourage  agencies  to 

experiment  determined  that  these  systems  could  procure  incident  management  and  awareness  tools  that  are 

provide  most  of  the  information  needed  for  awareness  MASAS  enabled.  It  is  suggested  that  the  Province  establish 

purposes.  The  integrations  could  geospatially  place  some  guidelines  and  standards  for  interconnected  systems, 
many  Emergency  Management  information  products  and  that  a  fund  be  created  that  can  grant  money  to  individual 

(such  as  situation  reports  and  resource  requests)  and  agencies  that  comply  with  these  guidelines  (including  MASAS 

the  linkages  are  present  in  the  alerting  messages  to  interfaces). 

allow  users  to  click  through  to  such  reports  if  they  were  -  Introduce  an  annual  provincial  interoperation  test  exercise, 
published  in  such  a  manner.  similar  to  the  integration  aspect  of  the  CAUSE  experiment, 

-  Making  a  film  of  the  project  was  a  very  effective  where  all  operationally  connected  systems  are  enhanced  to  the 

means  of  illustrating  and  disseminating  information  latest  interface  standards,  and  the  changes  are  then  tested 

regarding  the  project,  the  tools,  and  the  capabilities  of  through  exercise  of  an  operational  scenario  involving  actors  in 
the  integrations.  The  documentary  has  proven  popular  each  location.  Each  agency  involved  would  play  a  part  in  acting 
amongst  the  emergency  management  community  and  is  out  the  information  flows  and  validating  and  testing  the 

being  used  extensively  for  conferences  and  for  versioning  of  the  interfaces, 

fundraising  and  educational  purposes. 

HAZUS  (Vignette  1) 

Findings  -  see  section  7.4  Recommendations  -  see  section  7.5 

-  HAZUS  provided  useful  information  for  the  -  The  City  of  Richmond  might  evaluate  HAZUS  further  and 

municipality  understanding  the  impact  of  a  major  develop  an  understanding  of  resources  required  to  maintain  the 

earthquake.  HAZUS  model  and  information  sources. 

-  HAZUS  could  bring  together  much  of  the  existing  -  Future  experiments  could  explore  the  use  of  the  HAZUS 

Critical  Infrastructure,  building  and  population  output  models  and  interfaces  being  developed  by  NRCan  (e.g. 

information,  and  also  the  multiple  threat  models  CommunityViz  and  web  services  being  developed  by  Galdos). 

applicable  to  the  city.  -  It  is  recommended  that  the  NRCan  research  should  be 

-  There  was  concern  over  the  resource  required  to  developed  into  a  standard  provincial  framework  for  community 

gather  and  process  the  information,  the  security  of  threat  and  risk  modelling,  with  support  for  collaboration  and 

information  generated  and  how  much  the  models  could  sharing  of  resources,  development  of  information  sources, 

be  trusted.  threat  scenarios  and  tools  for  storage  and  dissemination  using 

-  Other  USGS/FEMA  tools  might  also  be  applicable  for  HAZUS  as  a  core  tool  in  the  process. 

use  by  the  city  (e.g.  real  time  feeds,  -  Future  experiments  could  explore  the  use  of  Shakecast 

PAGER/Shakemaps  and  Shakecast).  (running  off  similar  data  as  gathered  from  HAZUS). 
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Emergeo  /  AMECom  truck  (Vignette  2) 

Findings  -  see  section  8.4  Recommendations  -  see  section  8.5 

-  the  EmerGeo  Fusionpoint  product  demonstrated  the  -  It  is  recommended  that  the  city  of  Richmond  procure  and 

usefulness  of  map  based  incident  and  situational  implement  an  incident  management  and  situational  awareness 

awareness  system  and  the  availability  of  this  information  system  such  as  EmerGeo  Fusionpoint,  such  that  incidents  can 
for  remote  decision  makers.  be  tracked  and  managed  by  local  managers  and  can  be 

-  the  EmerGeo  Smart  Client  demonstrated  how  a  live  accessed  remotely  by  decision  makers. 

input  from  United  States  Geological  Survey  (USGS)  can  -  It  is  recommended  that  such  a  system  should  be  capable  of 
generate  ground  shake  models  and  an  initial  consuming  and  publish  alerting  messages  via  the  Multi-Agency 

assessment  of  the  potential  earthquake  impacts  Situational  Awareness  System  (MASAS)  for  sharing  information 

-  Web  Mapping  Service  (WMS  was  explored  as  a  with  other  neighbouring  jurisdictions  and  the  province, 

potential  integration  between  Fusionpoint  and  BCeMap,  -  There  is  overlap  between  the  capabilities  of  Fusionpoint  and 
however  additional  development  would  be  required  to  BCeMap  and  if  both  have  access  to  the  same  sources  (e.g. 
make  this  fully  functional.  MASAS  then  only  one  would  be  needed).  In  the  absence  of  a 

local  system,  BCeMap  could  be  made  available  for  situational 
awareness  purposes. 

-  It  is  recommended  that  various  critical  infrastructure  operators 
(for  example  Vancouver  International  Airport)  could  be 
approached  to  develop  operational  procedures  to  implement 
the  AMECom  truck  to  support  recovery  of  critical 


-  The  Ushahidi  web  site  was  an  easy  to  use  application  -  It  is  recommended  that  the  process  explored  in  the 

for  submission  of  public  reports.  experiment  is  developed  into  an  operational  process  for  use  in 

-  The  experiment  demonstrated  that  the  City  of  the  case  of  a  major  incident  or  event. 

Vancouver  31 1  contact  centre  team  could  effectively  -  A  means  by  which  operators  could  initiate  an  automatic 

evaluate  Ushahidi  reports  and  create  ETeam  call  centre  extraction  of  report  data  and  location  information  from  Ushahidi 

records.  These  could  then  be  converted  to  incident  into  ETeam  would  be  beneficial  in  terms  of  saving  time, 

reports  by  Emergency  Managers  if  deemed  appropriate,  -  Similar  interfaces  from  Facebook  and  Twitter  should  also  be 
and  published  as  map  events  in  BCeMap.  considered. 

-  It  is  recommended  that  policies  and  media  strategies  are 
developed  around  publicising  the  existence  of  event-related 
Ushahidi  sites  or  any  other  social  media  sites  deemed  useful 
for  the  public.  This  should  also  include  outbound 
communications  (e.g.  publicising  reception  centres  or  people 
finding  services). 
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BCeMap  /  MASAS  /  CAP/Atom  Scenario  Generator  (Vignette  4) 


Findings  -  see  section  9.4 

Recommendations  -  see  section  9.4  and  Appendix  A 

-  The  experiment  sponsored  the  implementation  of  an 
interface  on  BCeMap  that  consumes  messages  from  the 
latest  generation  of  MASAS  alerting  messages. 

-  The  experiment  allowed  a  significant  amount  of  testing 
with  real  CAP  messages  and  the  identification  of  issues 
(e.g.  with  NRCan  earthquake  feed),  and  for  subsequent 

fixes  to  be  made 

-  The  CAP/Atom  Scenario  Generator,  built  specifically 
for  the  experiment,  proved  very  useful  for  driving  the 
scenarios.  This  tool  is  now  published  as  an  open- 
source  component  on  the  MASAS  project  web  site  and 

has  been  used  for  other  exercises  since. 

-  The  update  periodicity  of  the  BCeMap  feed  processes 
is  deemed  to  be  too  infrequent  for  the  real-time  nature 
of  data  coming  through  MASAS. 

-  It  is  recommended  that  the  improvements  to  the  BCeMap 
delivery  process  are  implemented  as  listed  in  section  10.5. 

-  It  is  recommended  that  BCeMap  is  upgraded  to  the  latest 
version  of  the  Flex  API  such  that  the  open  source  MASAS  ESRI 
Flex  Tools  (MEFT)  can  be  implemented  in  BCeMap  and  can 
therefore  consume  alerting  messages  direct  from  MASAS.  This 
would  solve  the  issue  with  the  update  frequency  and  speed  of 
the  feed  processing,  and  also  minimise  any  potential 
compatibility  issues  with  future  messages  transmitted  through 

MASAS. 

-  It  is  recommended  that  BCeMap  should  be  upgraded  to  a 

multi-site  redundant  server  architecture  for  increased  resilience. 

-  It  is  recommended  that  the  CAP/Atom  message  generator  is 
enhanced  for  multi-language  support,  ability  to  send  alert 
updates,  and  other  general  improvements  (user  interface, 
coding  standards). 

-  The  list  of  CAP-CP  event  types  could  be  augmented  with  types 
to  cover  sensor  outputs  and  also  a  standard  means  of  indicating 
recent  updates. 

-  A  project  could  be  established  between  EMBC,  UBC  and  the 
BC  SIMS  Ministry  of  Transportation  to  develop  an  output  from 
the  bridge  sensors  and  strong  motion  ground  sensors  in  the 
SIMS  project  for  use  in  MASAS  and  BCeMap. 

Livewall/  SAMapper  (Vignette  5) _ 

Findings  -  see  section  1 1 .4 

-  Livewall  experienced  a  number  of  issues,  including 
hardware,  network  and  software  related  faults,  some  of 
which  were  overcome  but  ultimately  a  disk  failure 
rendered  the  solution  unavailable  for  the  experiment  at 
the  Canadian  end. 

-  SAMapper  was  bridged  through  an  adapter  on  the 
CAP/Atom  Scenario  Generator  through  to  MASAS  and 
from  there  to  BCeMap  to  demonstrate  cross  border 
interoperability. 


Recommendations  -  see  section  1 1 .5 

-  SAMapper  could  be  considered  as  a  simple  application  for 
gathering  tagged  images  from  field  devices  operated  by  first 
responders.  This  could  be  compared  to  other  similar 
applications  (including  Ushahidi).  Such  a  project  would  need 
to  consider  the  operational  procedures  related  to  the 
gathering  process  and  also  the  hardware  planned  for  such 
frontline  users. 

-  Although  it  was  demonstrated  that  direct  connection  to 
Canadian  parties  through  MASAS  is  technically  feasible,  it  is 
recommended  that  any  operational  alerting  messages  from 
the  US  transit  via  IPAWS  for  consistency  and  compliance 
with  national  standards  and  policy. 
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MASAS  /  IPAWS  /  MyStateUSA  (Vignette  6) 

Findings  -  see  section  12.4 

Recommendations  -  see  section  8.5 

-  Through  an  integration  between  IPAWS  and  MASAS, 
it  was  possible  to  interchange  data  between  BCeMap  in 
Canada  and  MyStateUSA  in  the  United  States. 

-  The  initiative  received  strong  support  from  the 
participants  and  there  is  significant  interest  in  pursuing 
this  further  amongst  all  parties.  This  has  led  to 
operational  and  technical  MOUs  signed  between  DRDC 
and  FEMA  to  further  develop  the  integration. 

-  There  were  some  challenges  in  terms  of  stability  and 
compatibility  of  the  VPN  network  connection,  evolving 
code  bases  and  message  content  incompatibilities. 

-  The  experiment  demonstrated  the  benefit  of  system- 
to-system  messages  allowing  information  to  flow  that 
might  normally  be  limited  by  the  hierarchical  nature  of 

cross-  border  relations. 

-  It  is  recommended  that  further  projects  are  pursued  to 
develop  the  governance,  operational  procedures,  technology, 
training/exercises  and  real-usage  testing  that  would  allow  the 
effective  implementation  cross-border  alerts. 

-  Such  project  initiatives  might  engage  senior  management  at 
FEMA  IPAWS,  NIEM  PMO  (National  Information  Exchange 
Model  Program  Management  Office)  and  the  PM  ISE  (Program 
Manager  for  the  Information  Sharing  Environment) 
organizations. 

-  It  is  recommended  that  IPAWS  is  enhanced  to  allow  CAP-CP 

messages  to  be  passed  natively  and  not  limited  by  the  strict 

CAP-1  PAWS  rules. 

-  It  is  also  recommended  that  the  CAP-1  PAWS  event  code  list 

is  expanded  and  mapped  to  the  CAP-CP  event  code  list,  or  to 
develop  a  shared  event  code  list  that  is  not  profile  specific  but 
can  be  included  in  CAP  messages  to  ease  translation  between 

more  localized  event  code  lists. 
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6.  CAUSE  Resiliency  (West  Coast)  Experiment  2011  Project 


6. 1  Introduction 

6.1 .1  This  project  is  part  of  an  annual  series  of  experiments  sponsored  by  Command,  Control  and  Interoperability  (CCI) 
Division  of  DHS  and  the  Centre  for  Security  Science  (CSS)  of  DRDC. 

6.1.2  These  experiments  are  intended  to  showcase  newly  operational/emerging  technologies,  to  guide  future  research 
and  development  and  to  improve  interoperability.  They  involve: 

•  Design,  planning,  preparing,  conduct,  after-action  analysis,  and  experiment  outreach  activities 

•  Cross-border  systems-integration  and  information  sharing  across  U.S.  States  and  Canadian  Provinces 

•  Collaboration  between  US  and  Canadian  first  responders  and  emergency  managers 

•  Multi-jurisdictional  and  cross-border  coordination  in  response  to  a  natural  disasters  as  well  as  ability  to  handle 
all  other  hazards 

6.1.3  The  projects  should  generate  leave-behind  benefits  in  terms  of  enhancements  to  fielded  technologies  (and  their 
use)  and/or  to  other  steps  on  the  SAFECOM  "Interoperability  Continuum"1  (i.e.  improvements  to  Governance, 
Standing  Operating  Procedures,  Technology,  Training  and  Exercises  or  Usage). 

6.1.4  The  CAUSE  Resiliency  (West  Coast)  Experiment  2011  project  began  in  the  summer  of  2010  for  the  Canadian 
participants;  it  started  with  a  workshop  hosted  at  the  Justice  Institute  of  BC  which  was  attended  by  a  number  of 
interested  Canadian  and  US  stakeholders.  It  was  agreed  at  that  workshop  to  target  a  May  2011  implementation 
timeframe  and  lists  of  candidate  technologies  and  participants  were  identified  and  discussed. 

6.1.5  Emergency  Management  BC  became  the  sponsor  in  situ  for  the  project  and  provided  overall  governance, 
prioritisation  and  guidance  with  respect  to  participation  and  technical  interest  Funding  was  provided  by  the  DRDC 
and  by  in-kind  contributions  from  participants.  The  main  execution  was  coordinated  with  the  US  counterparts,  with  the 
experiment  ultimately  conducted  on  21st  June  2011,  working  around  other  provincial  commitments  relating  to  spring 
flooding  this  year. 

6.1.6  The  project  was  managed  by  Planetworks  Consulting  Corporation  who  facilitated  a  series  of  focussed  meetings, 
workshops  and  bi-weekly  update  sessions  with  the  stakeholders,  international  (US)  partners,  suppliers  and  the 
technical  resources  involved  as  the  project  progressed.  Contracts  were  put  in  place  and  managed  by  Planetworks  for 
specific  integration  designs,  open-source  developments,  and  hosted  instances  of  commercial  software,  all  required  to 
build  the  environments  necessary  for  the  experiment,  and  to  ensure  the  resultant  leave-behind  components  and 
technology  improvements. 

6.1 .7  The  CAUSE  201 1  project  was  filmed  in  the  primary  Canadian  locations  and  included  interviews  with  stakeholders 
in  Ottawa  and  in  the  main  US  location.  The  intent  is  to  produce  a  documentary  of  the  process  for  wider  distribution.  A 
local  film  production  company,  Screaming  Black  Dog  Productions,  was  engaged  for  this  purpose  and  was  involved  in 
experiment  planning  and  script  development  to  assist  in  recording  the  event. 

6. 2  Objectives  of  Experiment 

6.2.1  The  project  envisioned  for  the  CAUSE  Resiliency  (West  Coast)  Experiment  2011  was  designed  purposefully  to 
engage  the  operational  emergency  management  communities  in  British  Columbia  and  bordering  organizations  in  the 
United  States,  and  to  demonstrate  the  use  and  integration  of  some  emerging  technologies  that  have  recently  been 
developed  or  are  near  operational  readiness. 

6.2.2  The  overall  goals  were  to: 

•  Encourage  adoption  and  active  use  of  those  technologies; 

•  Demonstrate  multi-jurisdictional  and  cross-border  collaboration; 

•  Guide  future  research  and  development  activities;  and 

•  Further  the  interoperability  and  value  of  existing  tools 

6.2.3  The  project  output  includes  this  report  which  contains  specific  recommendations  for  future  research  and 
development  activities,  as  well  as  providing  suggestions  for  initiatives  that  could  be  undertaken  by  participating 
organisations. 


1  http://www.safecomprogram.gov/SiteCollectionDocuments/lnteroperability_Continuum_Brochure_2.pdf 
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6.2.4  The  documentary  output  of  the  project  is  in  post-production  at  the  time  of  writing,  and  is  being  aimed  at  several 
target  audiences  including: 

•  EOC  operators/managers,  who  need  to  appreciate  what  the  tools  do,  and  why  they  should  care; 

•  Science  &  Technology  managers,  who  are  looking  to  gain  insight  into  how  their  outputs  are  making  a 
difference  in  operations; 

•  Regional  managers  at  all  levels,  who  may  be  unaware  of  the  maturity  of  tools  that  are  actually  going 
operational,  or  have  recently  become  available;  and 

•  Senior  decision  makers  at  Federal  and  Provincial  level,  who  may  be  recipients  of  the  video  clips  at  briefings 
and  who,  it  is  hoped,  would  be  impressed  with  the  value  of  outputs  that  are  being  generated  at  the  program 
level,  and  by  the  resulting  “interoperability  enhancements”. 

6.3  Overview  of  the  Experiment  Approach-  Canadian  Participation  and  US  Partnership 

6.3.1  The  CAUSE  2011  project  consisted  of  two  main  sub-projects.  The  Canadian  sub-project  was  managed  by 
Planetworks  on  behalf  of  the  CSS,  DRDC.  The  other  US  project  was  managed  by  the  PNNL  based  out  of  Seattle,  WA 
and  sponsored  by  the  DHS,  CCI  division. 

6.3.2  Somewhat  different  approaches  to  achieving  the  common  goals  were  adopted  by  each.  This  variance  stemmed 
mainly  from  dissimilar  technology  selection  processes. 

6.3.3  The  Canadian  project  focused  on  key  technologies  that  were  of  interest  to  select  operational  parties  who  were 
consulted  as  the  process  evolved.  These  tended  to  be  technologies  that  were  known  to  be  close  to  production-ready 
or  already  in  use,  and  it  was  felt  that  this  experiment  presented  an  opportunity  to  evaluate  and  explore  various 
technical  integrations  or  operational  combinations. 

6.3.4  The  PNNL  approach  was  to  explore  a  significant  number  of  technologies  (the  evaluation  list  exceeded  36 
products)  that  were  funded  previously  by  DHS  programs  and  to  evaluate  their  fit  and  merit  in  an  emergency 
management  context.  This  was  not  necessarily  the  customer  base  that  a  number  of  the  technologies  were  developed 
for. 

6.3.5  Once  the  respective  technologies  were  determined,  the  process  to  determine  possible  interoperability  between 
the  Canadian  technologies  and  US  technologies,  and  matching  operational  scenarios  that  might  illustrate  interaction 
between  participating  agencies  north  and  south  of  the  border  began. 

6.3.6  Figure  1  illustrates  the  timelines  of  the  phases  of  the  project.  Participating  Canadian  agencies  were  identified 
early  in  the  process,  with  some  integration  developments  initiated  in  early  2011.  Exploration  of  integrations  and 
implementation  continued  through  until  late  in  the  process. 
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Summary  Timeline 
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Establish  Possible  Interfaces  &  Cost/Timelines 
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- > 


Contracts 


2011 

Mar  Apr  May  June 


evelopScenario(s) 


Develop  & 


Implement 


->  Test 


Dry 

Run 

V7  June  14th 

Experiment 

Execution 

June  21st 


Figure  1  -  Project  Timelines 


6.3.7  Operational  scenario  development,  including  the  development  of  the  data  test  packs  required  to  provide  context 
for  the  scenarios,  also  ran  through  until  the  live  experiment  date.  By  the  time  of  the  dry-run  date  most  of  the 
technologies  were  available  or  had  been  made  available  to  the  participating  agencies,  allowing  final  touches  to  be 
made  to  the  main  script,  ready  for  the  main  execution  date  a  week  later. 

6.3.8  Filming  was  also  carried  out  on  the  dry-run  date.  This  provided  an  opportunity  for  the  experiment  logistics  to  be 
rehearsed  and  the  timing  and  movement  of  film  crews  with  participating  groups  and  actors  to  be  practised,  and  for 
network  connectivity  to  be  tested,  web  cast  installed  and  issues  to  be  identified.  Filming  on  this  day  allowed  “B  Roll”  to 
be  captured  i.e.  backup  footage  to  fill  gaps  on  the  main  shoot,  in  some  cases  the  sequences  were  good  enough  not  to 
need  repeating  on  the  main  execution  day,  allowing  more  time  for  other  segments. 


6.4  Participation  and  Technologies  of  Interest 

6.4.1  North  of  the  border,  the  following  participants  agreed  to  be  part  of  the  experiment.  Their  specific  interests  are 
also  listed  (these  technologies  are  referenced  in  this  section  and  explained  in  more  detail  in  section  6): 

•  EMBC,  in  particular  the  South  West  Provincial  Regional  Emergency  Operations  Centre  (PREOC),  which  was 
interested  in  additional  information  sources  including  the  Multi-Agency  Situational  Awareness  System 
(MASAS)  alert  messages  for  BCEMap  which  is  the  provincial  emergency  mapping  tool,  and  also  sources 
listed  below  (EmerGeo  and  Hazus-MH).  EMBC  were  also  interested  in  the  possibility  of  Tsunami  alerts  being 
generated  through  MASAS  for  BC  and  also  the  use  of  Hazus-MH  for  developing  consistent  threat/hazard  and 
damage  models  across  municipalities  in  the  province. 

•  Vancouver  Emergency  Management  and  Vancouver  City  31 1  Call  Centre,  which  were  interested  in  using 
social  media  and  crowd  sourcing  tools  such  as  Ushahidi  to  gather  information  from  the  public  and  have 
incident  information  created  as  a  result  in  the  formal  emergency  management  systems  (E  Team  and 
BCeMap). 

•  Richmond  Emergency  Management,  which  was  interested  in  exploring  an  on-line  emergency  management 
tool  called  EmerGeo  Fusionpoint,  and  the  EmerGeo  Smart  Client  tool  and  also  willing  to  evaluate  use  of  a  risk 
and  damage  assessment  tool  called  Hazus-MH. 

6.4.2  The  main  expenditure  on  interfaces  as  part  of  the  project  was  for  the  MASAS/BCeMap  interface,  for  which  a 
contract  was  negotiated  with  ESRI  in  early  2011.  The  main  scenario  generation  tool  development  was  also  started  in 
early  2011.  Other  possible  integrations  between  EmerGeo,  Hazus-MH  and  BCeMap  were  identified  and  progressed  in 
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parallel.  Testing  of  the  integrations  ran  through  until  the  dry  run  date,  and  up  until  the  main  execution  date. 

6.4.3  One  of  the  systems  that  were  considered  for  inclusion  in  the  experiment  was  the  BC  Smart  Infrastructure  Systems 
(BCSIMS),  a  project  being  managed  by  the  University  of  British  Columbia  (UBC)  on  behalf  of  the  Ministry  of 
Transportation.  Conceivably  this  system  might  have  provided  two  important  sources  of  information  for 
MASAS/BCeMap  in  the  context  of  a  major  earthquake  i.e.  input  from  strong  motion  sensors,  which  would  give 
readings  for  the  level  of  shaking  at  various  locations,  possibly  an  iso-map  of  intensity  of  the  effects  of  the  earthquake, 
and  also  input  from  bridge  seismic  sensors  which  would  indicate  where  bridges  have  exceeded  their  design  limits. 

6.4.4  Unfortunately,  due  to  other  project  pressures  on  BCSIMS  team,  this  was  not  possible  for  this  experiment,  and  the 
input  was  simulated  instead  using  a  message  generation  tool  in  order  to  provide  input  into  the  scenarios.  It  is 
recommended  however  that  a  future  experiment  would  provide  a  means  for  implementing  this  feed  from  BCSIMS  into 
MASAS  and  therefore  to  other  consuming  systems. 

6.5  Canadian  /  US  Interoperation 

6.5.1  One  significant  focus  of  the  CAUSE  2011  project  was  the  interoperation/integration  between  Canadian  and  US 
organisations  and  technologies. 

6.5.2  A  number  of  explorations  were  made  in  both  the  Canadian  and  USA  projects  to  find  potential  interest  and 
partners  between  the  major  interoperability  technologies  in  the  USA,  including  Virtual  USA  (a  project  to  develop  GIS 
interoperability  standards  between  agencies)  and  projects  relating  to  the  Unified  Incident  Command  and  Decision 
Support  (UICDS)  middleware.  Figure  2  shows  a  diagram  covering  the  potential  integration  concepts  that  were 
explored.  There  was  significant  interest  in  many  of  the  related  projects  that  might  have  been  persuaded  to  be 
extended  to  encompass  a  cross  border  component.  However  in  most  cases  the  level  of  work  required,  as  well  as  the 
lead-time  involved  in  confirming  the  budget  and  assigning  development  resources  proved  impractical  in  the  time 
available. 
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6.5.3  Two  cross-border  initiatives  were  taken  forward  however.  These  were,  in  summary: 

6.5.4  SAMapper  Integration:  The  simplest  integration  was  Option  7  in  Figure  2,  where  a  tool  called  SAMapper,  one  of 
the  tools  chosen  in  the  US  project  required  a  small  amount  of  development  that  enabled  delivery  of  that  product’s 
database  contents  via  XML  over  http,  which  could  be  picked  up  by  an  adapter  at  the  Canadian  end,  essentially  an 
add-on  to  the  scenario  generation  tool  built  for  the  project,  which  could  then  re-publish  to  the  MASAS  hub  and  for 
consumption  by  any  system  connected  to  MASAS  (including  BCeMap). 

6.5.5  MyStateUSA>IPAWS>MASAS  Connection  Development:  Another  track  that  was  also  successfully  explored, 
through  the  MASAS  National  Infrastructure  Team  (NIT)  who  reached  out  to  the  Washington  State  Emergency 
Management  Department  and  their  Emergency  Operations  Center  which  uses  a  MyStateUSA  system  to  issue  and 
receive  CAP  alerts  through  DM  Open  (subsequently  migrated  to  IPAWS  OPEN  in  June  of  this  year).  MyStateUSA 
was  contacted  and  they  were  keen  to  be  involved  in  order  to  develop  the  MyStateUSA  brand  in  Canada.  A  contract 
resource  was  engaged  by  CSS  to  move  the  project  forward,  develop  the  operating  scenarios  and  work  with  the 
MASAS  NIT  to  coordinate  development  of  the  MyStateUSA>IPAWS>  MASAS  connections. 

6.5.6  As  a  result  of  these  initiatives,  two  cross  border  technical  connections  were  incorporated  into  the  master  scenario 
and  into  the  vignettes  that  were  used  to  engage  the  emergency  management  organizations  involved. 

6.6  Overview  of  the  Experiment  Execution  -  Master  Scenario  and  Locations  involved 

6.6.1  The  experiment  itself  involved  a  series  of  vignettes  that,  in  turn,  were  based  on  a  master  scenario  that  was 
developed  around  a  large  Cascadian  subduction  zone  earthquake  of  Magnitude  9.0.  This  provided  context  for  the 
time  slices  chosen  for  the  vignettes.  These  were  points  in  time  where  information  flows  around  the  event  and  related 
incidents  were  simulated,  involving  information  moving  between  systems  and  engaging  players  in  different  locations  in 
dialogue  around  those  information  flows. 

6.6.2  For  a  magnitude  9.-0  subduction  earthquake,  it  would  be  normal  to  expect  tens  to  hundreds  of  aftershocks  over  a 
period  of  a  few  weeks.  A  few  of  these  aftershocks  would  be  a  magnitude  between  6  and  7.5,  possibly  within  an  hour 
of  the  main  event  but  more  likely  to  occur  later.  Aftershocks  can  occur  in  a  cluster. 

6.6.3  The  location  of  the  aftershocks  would  be  random.  The  main  rupture  may  be  500-800  km  long  and  aftershocks 
could  be  in  any  of  the  fault  lines  in  the  region. 

6.6.4  The  baseline  scenario  used  for  the  CAUSE  201 1  project  was  one  of  the  scenarios  published  by  the  USGS  at 
http://earthauake.usqs.aov/earthauakes/shakemap/global/shake/Casc9.0  se/  and  illustrated  in  Figure  3. 
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--  Earthquake  Planning  Scenario  -- 
ShakeMapfor  Case 9.0  Scenario 

Scenario  Date:  Wed  Jul  13,  2D1 1  12:00:00  GMT  M9.0  N45.73  W125.12  Depth:  D. 0km 
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Figure  3  -  Cascadian  9.0  Planning  Scenario 

6.6.5  The  locations  involved  in  the  experiment,  and  the  approximate  location  of  the  major  earthquake  are  shown  in 
Figure  4. 
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Figure  4  -  Experiment  Locations 


6.6.6  The  Canadian  locations  involved  in  the  experiment  were  as  follows: 

•  The  Provincial  Emergency  Coordination  Centre  (PECC). 

•  The  South  West  Provincial  Regional  Emergency  Operations  Centre  (SW  PREOC).  Located  at  14275,  96th 
Avenue,  Surrey. 

•  The  Vancouver  Emergency  Operations  Centre.  Co-located  with  the  Emergency  Communications  for  South 
West  British  Columbia,  3301  E  Pender  Street,  Vancouver. 

•  The  Vancouver  City  31 1  Call  Centre.  Co-located  with  the  Emergency  Communications  for  South  West  British 
Columbia,  3301  E  Pender  Street,  Vancouver. 

•  The  Richmond  Emergency  Operations  Centre.  Located  at:  691 1  No.  3  Road,  Richmond 

6.6.7  The  emergency  management  command  and  control  protocols  in  British  Columbia  follow  an  Incident  Command 
Systems  (ICS)  in  accordance  with  the  British  Columbia  Emergency  Response  Management  System  (BCERMS).  The 
processes  followed  in  the  experiment  reflected  these  protocols,  with  some  license  taken  for  the  sake  of  dramatization, 
for  example  omitting  the  initial  processes  for  opening  up  communications  with  US  counterparts,  or  allowing 
communication  situation  reports  to  be  provided  verbally  rather  than  on  paper. 

6.6.8  The  PECC  provides  policy  direction,  coordinating  the  overall  provincial  response  and  resources,  establishing 
provincial  government  priorities,  liaising  with  federal  and  international  assistance  agencies  and  supporting  a  24/7 
incident  reporting  line  for  the  province. 

6.6.9  The  SW  PREOC  is  one  of  five  provincial  emergency  operations  centres,  whose  role  is  to  coordinate  and  prioritize 
the  province’s  response  to  emergencies  and  disasters  within  a  designated  region,  in  this  case  the  lower  mainland 
area,  and  also  to  coordinate  provincial  and  agency  support  for  local  authorities,  First  Nations  or  other  provincial 
ministry  or  agencies.  The  PREOC  also  reports  directly  to  and  takes  policy  direction  from  the  Provincial  Emergency 
Coordination  Centre.  Reports  include  situational  information  on  events  within  the  region  as  well  as  resource  requests 
in  situations  where  appropriate  and/or  where  sufficient  resources  are  not  available  within  the  region. 

6.6.10  The  Vancouver  and  Richmond  Emergency  Operations  Centres  undertake  planning  to  maximize  the  protection  of 
life,  public  infrastructure,  private  property  and  the  environment  for  their  respective  communities  in  the  event  of  a  major 
emergency  or  disaster.  The  centres  also  conduct  emergency  operations  to  protect  life  and  property.  The  EOC  is  a 
facility  where  key  city  personnel  and  other  response  agencies  gather  to  provide  policy  direction  to  the  on-site  incident 
commanders,  as  well  as  to  co-ordinate  resource  requests  from  the  incident  sites.  Their  role  is  also  to  sustain  business 
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operations  and  to  rebuild  in  order  to  restore  economic  viability  after  an  event. 

6.6.11  The  Vancouver  311  Call  Centre  is  the  call  handling  service  for  the  Vancouver  City  citizens’  service  line  that 
handles  citizen  requests  for  service,  information  and  reporting  concerns. 

6. 7  Overview  of  the  Experiment  Execution  -  Vignettes 

6.7.1  Over  the  course  of  the  experiment  development  a  number  of  vignettes  were  developed  against  the  backdrop  of 
the  overall  scenario.  These  were  evolved,  and  the  storyline  script  developed  as  the  integrations  were  implemented 
and  the  touch  points  with  the  US  organizations  were  developed.  The  detailed  script,  included  at  Appendix  B,  was 
used  to  guide  the  actors  in  using  the  technologies  and  the  dialogue  for  the  filming. 

6.7.2  Figure  5  illustrates  how  each  of  the  technologies  was  employed  to  implement  information  communication  between 
organizations  and  locations  and  was  used  to  support  the  dialogue. 
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Figure  5  -  Overview  of  Vignettes  Locations  Inter-operation  and  Technologies 


6.7.3  Vignette  1:  Modelling/Planning  before  the  earthquake  event:  Involved  a  planning  session  between  a  NRCan 
project  team  and  the  City  of  Richmond,  using  a  damage  assessment  and  modeling  tool  called  Hazus-MH.  A  dialogue 
was  also  supported  with  the  Provincial  Seismic  Specialist  (based  at  EMBC/PECC)  and  an  integration  between  Hazus- 
MH  and  the  provincial  emergency  awareness  map  tool  called  BCeMap.  This  vignette  is  described  in  detail  in  section 
7.  The  ability  to  run  some  risk  and  damage  assessment  models  for  Richmond  was  made  possible  by  a  significant 
NRCan  project  (funded  under  the  DRDC  CRTI  umbrella)  that  developed  generic  data  sources  for  Metro  Vancouver 
(an  area  which  includes  Richmond).  The  vignette  was  designed  to  expose  Richmond  Emergency  Management  to  the 
Hazus-MH  tool,  the  risk  assessment  process  and  the  possible  outputs  for  use  in  planning  against  specific  threat 
scenarios. 

6.7.4  Vignette  2:  EOC  Activation  and  Situation  Assessment:  Based  around  the  activation  of  the  Richmond  EOC, 
including  the  initial  briefings  for  staff  as  they  arrived,  using  EmerGeo  Fusionpoint  as  the  incident  management  system 
and  consolidated  dashboard,  as  well  as  using  the  EmerGeo  smart  client  to  assess  the  potential  ground  shake  effects. 
A  briefing  dialogue  is  held  between  Richmond  EOC  and  the  SWPREOC,  including  use  of  an  output  from  EmerGeo 
Fusionpoint.  Several  Hazus-MH  outputs  relating  to  Richmond  were  also  published  to  BCeMap  (to  be  visible  to  the 
SWPREOC)  during  the  briefing,  exploring  the  integrations  of  these  tools. 

6.7.5  Vignette  3:  Viaduct  Collapse  and  Crowd-sourcing  Incident  information:  Involving  several  locations,  the 
vignette  simulated  a  collapse  of  the  Georgia  viaduct,  with  members  of  the  public  reporting  information  into  a  crowd 
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sourcing  application  called  Ushahidi.  The  City  of  Vancouver  311  Call  Centre  assessed  the  public  reports  within 
Ushahidi,  and  entering  validated  reports  into  the  Vancouver  EOC  E  Team  system,  ultimately  allowing  these  events  to 
appear  in  BCeMap  and  to  be  viewed  at  the  South  West  PREOC. 

6.7.6  Vignette  4:  SW  PREOC  Regional  Roll-up:  In  this  vignette  an  overview  briefing  session  was  held,  providing  a 
roll-up  of  information  across  the  Lower  Mainland  including  information  coming  in  from  bridge  sensors,  strong  motion 
ground  sensors,  messages  generated  by  the  PECC  regarding  tsunamis  and  EOC  activations,  municipal  information 
from  Richmond  and  Langley  and  highway  information  such  as  rock  falls  that  effectively  block  access  to  the  Lower 
Mainland  and  set  the  scene  for  investigating  moving  resources  through  the  US  in  the  following  vignettes. 

6.7.7  Vignette  5:  US  Transportation  Route  Investigation  -  Seattle  EOC:  This  vignette  was  one  of  the  touch  points 
with  the  US  projects,  in  which  a  situational  briefing  was  held  between  the  SW  PREOC  and  the  Seattle  EOC 
(simulated  during  the  PNNL  demonstration  session).  The  SAMapper  interface  to  BCeMap  via  MASAS  hub  was  used 
to  illustrate  the  state  of  major  highways  in  the  Seattle  area.  This  was  important  for  the  SW  PREOC  in  assessing  the 
possibility  of  moving  resources  between  the  interior  and  the  Lower  Mainland  via  the  highways  in  the  US. 

6.7.8  Vignette  6:  US  Transportation  Route  Investigation  -  WA  EMD-  This  vignette  involved  the  integration  of  the 
MyStateUSA  system  used  by  Washington  State  Emergency  Management  Department  and  systems  in  Canada  via  the 
major  US  and  Canadian  alerting  messaging  hubs  (IPAWS  and  MASAS).  This  supported  a  dialogue  between  the  SW 
PREOC  and  Washington  State  Emergency  Management  Department  regarding  the  state  of  highways  across  the  state 
and  between  Seattle  and  the  border. 

6.7.9  Vignette  7:  Deployment  of  AMECOM  Truck  -  deployment  of  the  Province’s  tactical  emergency  communication 
vehicle  was  requested  and  discussed  with  the  City  of  Richmond  in  Vignette  2  and  the  deployment  of  the  truck  to 
Vancouver  International  Airport  was  simulated.  Due  to  time,  scheduling  and  budget  limitations,  this  vignette  was  de- 
scoped  and  in  the  findings  incorporated  into  Vignette  2  for  the  purposes  of  the  report. 
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7.  Overview  of  the  Technologies  Involved  in  the  Experiment 

7.1.1  The  following  sections  give  a  brief  overview  of  the  technologies  involved  in  the  experiment  from  both  the 
Canadian  project  and  the  American  systems  that  were  interfaces  with.  The  details  of  the  integrations  are  included  in 
each  of  the  vignette  descriptions. 

7.2  BCeMap 

7.2.1  BCeMap  is  British  Columbia’s  situational  awareness  and  emergency  mapping  system.  The  system  was 
developed  by  ESRI  and  hosted  at  GeoBC  (now  Citizens  Services)  on  behalf  of  EMBC,  the  main  sponsor  of  the 
project.  The  system  is  currently  in  production  for  use  by  the  Provincial  Emergency  Operations  Centres  and  brings 
together  multiple  static  layers  together  with  several  dynamic  data  feeds  to  present  a  single  browser  based  map  for 
users. 
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Figure  6  -  BCeMap  Architecture 


7.2.2  Figure  6  shows  the  architecture  of  BCeMap,  how  the  static  layers  and  wild  fire  feeds  are  served  up  from  the  Land 
and  Resource  Data  Warehouse  (LRDW)  together  with  feeds  from  Drive  BC,  Environment  Canada  Weather,  NRCan 
Earthquakes,  incidents  from  E  Team,  the  provincial  incident  management  system,  and  also  a  data  feed  from  the 
original  pilot  version  of  MASAS  (MASAS  1 ). 

7.2.3  For  the  experiment,  BCeMap  was  upgraded  to  be  able  to  consume  the  latest  MASAS  II  feed  using  a  dedicated 
MASAS  hub  used  for  the  experiment  (to  control  the  data  sources  during  the  experiment)  and  was  also  configured  to 
use  data  from  several  WMS  sources  (NRCan  Hazus-MH  output  and  EmerGeo  WMS  output)  in  order  to  explore  the 
possibilities  of  using  BCeMap  as  a  main  delivery  mechanism  of  such  data  to  users. 

7.2.4  For  more  detail  on  the  BCeMap  system,  the  upgrade  project  details  and  the  recommendations  see  Appendix  A. 

7.2.5  BCeMap  is  in  the  process  of  being  made  operational  for  use  in  the  PECC  and  PREOCs  over  the  next  few  weeks, 
in  parallel  with  training  on  E  Team.  It  is  anticipated  that,  in  the  spring  of  2012,  MASAS  will  be  exposed  more  broadly 
across  the  province  and  that  a  further  rollout  of  BCeMap  to  include  participating  Local  Authorities  and  other  EM 
stakeholders  will  be  considered  at  that  time. 
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7.2.6  A  sample  screenshot  from  BCeMap  with  the  current  Earthquakes  feed  active  is  shown  in  Figure  7. 


Figure  7  -  Earthquakes  in  the  region  in  normal  times  (a  three  week  period  in  November  2010) 

7.3  Hazus-MH 

7.3.1  The  National  Resources  Canada,  Geological  Survey  of  Canada  Earth  Sciences  Sector  has  a  mandate  sponsored 
by  CRTI  to  adapt  a  FEMA  developed  tool  called  HAZUS-MH  for  use  in  Canada,  and  to  incorporate  it  into  a  broader 
framework  for  integrated  risk  assessment  (Pathways-DM)  that  is  aligned  with  the  national  All-Hazards  Risk 
Assessment  Framework  (AHRA)  that  DRDC  and  Public  Safety  Canada  are  developing.  Much  of  the  work  is  aimed  at 
allowing  HAZUS  to  be  used  anywhere  in  Canada,  using  available  data  sources  made  accessible  through  an  Asset 
Inventory  Management  System  and  using  threat  modeling  developed  specific  to  Canada’s  environment  and 
geography. 


HAZUS-MH  MR4 


Welcome  to  HAZUS-MH  MR4  Setup. 

This  setup  will  install  HAZUS-MH  on  your  computer  To  continue,  dick  Next 


<  Back  Next  >  j  Cancel 

Figure  8  -  Image  of  Hazus-MH  set-up  screen 

7.3.2  A  project  called  “Methods  and  tools  to  compile  a  regional-level  Asset  Inventory  Management  System  database  in 
Canada”  was  set  to  up  to  explore  the  possible  sourcing  and  integration  of  data  from  various  sources  to  form  the  basis 
of  a  standard  data  set  that  would  allow  interested  parties  (e.g.  municipalities  and  utilities)  to  start  from  a  common 
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baseline  and  not  have  to  perform  the  work  themselves  to  obtain  the  data  from  those  standard  sources.  Planetworks 
was  involved  in  that  project  and  was  subcontracted  to  investigate  sources,  assist  with  agreements  to  use  the  data  and 
also  the  technology  to  process  and  load  into  the  Asset  Inventory  Management  System  (AIMS)  database.  This  work 
directly  supported  the  ability  to  run  models  in  the  context  of  Richmond  since  the  scope  was  the  region  covered  by 
Metro  Vancouver  (Greater  Vancouver  Regional  District).  The  overall  process  is  shown  in  Figure  9.  The  data 
developed  for  this  project  was  used  in  the  CAUSE  201 1  experiment  and  the  model  outputs  used  in  the  vignettes. 
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Figure  9  -  Hazus-MH  Process  for  Greater  Vancouver 


7.4  Ushahidi 

7.4.1  Ushahidi  is  a  non-profit  technology  company  that  develops  free  and  open  source  software  for  information 
collection,  visualisation  and  interactive  mapping.  The  “Ushahidi  Platform”  is  one  of  the  tools  developed  by  this 
community  to  allow  crowd-sourcing  of  information  from  multiple  channels,  including  SMS,  email,  Twitter  and  the  web 
to  create  online  reports  that  are  visually  represented  on  a  map. 

7.4.2  Volunteers  or  organisations  create  and  host  instances  of  the  platform  to  support  information  gathering  relating  to 
events  such  as  elections  (to  monitor  ballot  rigging),  human  trafficking  or,  pertinent  to  this  project,  large  scale  disasters, 
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such  as  the  Christchurch  or  Japanese  earthquakes. 

7.4.3  The  Ushahidi  site  set  up  to  track  infrastructure  damage  in  Christchurch  is 
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shown  in  Figure  10. 
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Figure  10  -  Christchurch  Infrastructure  Ushahidi  Site 


7.5  NC4  E  Team 

7.5.1  In  order  for  decision  makers  to  know  what  is  going  on  during  an  emergency  there  is  a  need  to  have  accurate 
information  pooled,  sorted  and  available  in  order  to  achieve  situational  awareness  and  plan  appropriate  responses. 
The  emergency  management  information  service  (EMIS)  program  is  designed  to  provide  a  system  that  facilities 
situational  awareness.  EMIS  allows  participating  organizations  to  share  real-time  emergency  management  information 
and  data,  including  maps.  At  the  centre  of  the  BC  EMIS  strategy  is  the  E  Team  secure  web  application. 

7.5.2  The  E  Team  system  is  used  to  store  critical  information  such  as  Situation  Reports,  Resource  Requests  and 
Incidents,  all  available  for  mass  consumption  by  each  user  group  during  an  emergency.  E  Team  enables  each  of  the 
four  pillars  in  EMBC-  Planning,  Logistics,  Finance  &  Admin,  and  Operations,  to  gather  information,  approve  resource 
requests,  report  information  and  to  pass  mission  critical  data  from  one  organizational  group  to  another. 

7.5.3  EMBC  has  also  used  E  Team  web  services  interface  that  allows  incidents  to  be  pulled  from  the  system  and 
presented  in  EMBC’s  common  operating  picture  “BCeMap”. 

7.5.4  Figure  1 1  shows  an  incident  list  in  E  Team. 
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Figure  11  -  Incident  list  in  E  Team 


7.5.5  Other  Reports  that  EMBC  utilizes: 

•  Incident  and  Emergency  Event  reporting 

•  Resources  and  Critical  Assets  management 

•  Planned  Events  and  Activities  reporting 

•  Full  Mapping  and  Overlay  capability  with  Universal  Console 

•  WSDL  Web  Services  support 

•  Agency  Situation  reporting  for  situation  reports 

•  Call  Center  reporting 

7.6  EmerGeo  Fusionpoint 

7.6.1  EmerGeo  Solutions  Inc.  has  been  developing  and  implementing  crisis  management  and  situational  awareness 
software  and  services  to  clients  worldwide  since  2002. 

7.6.2  EmerGeo’s  flagship  product,  Fusionpoint,  provides  EOCs  and  field  personnel  with  a  web  dashboard  that 
integrates  data  from  disparate  systems  such  as  9-1-1  dispatch,  Automatic  Vehicle  Locations  systems,  crisis 
management  software,  news  feeds,  CCTV  cameras  and  GIS  mapping;  enhanced  capabilities  include  publishing  and 
consuming  data  via  interoperable  systems  using  WMS,  KML  and  GeoRSS. 

7.6.3  More  recent  capabilities  include  the  ability  to  consume  MASAS  messages,  although  this  feature  was  not  released 
in  time  to  be  incorporated  in  this  experiment. 

7.6.4  Fusionpoint  provides  a  configurable  web-based  and  portable  crisis  management  system  with  features  such  as 
incident  logging  and  reporting,  task  management,  resource  management,  mapping  and  hazard  modeling,  and 
automated  alerting. 
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Figure  12  -  EmerGeo  Fusionpoint  Dashboard 


7.7  EmerGeo  Smart  Client 


7.7  A  EmerGeo  Smart  Client  is  part  of  the  EmerGeo  Fusionpoint  suite  that  manages,  authors  and  publishes  information 
to  other  web  or  thick  client  (mobile)  users  and  provides  advanced  mapping  capabilities  such  as  hazard  modeling  and 
impact  analysis.  EmerGeo’s  web  and  mobile  mapping  solutions  provide  a  common  operating  picture  that  uses  the 
Open  GIS  Consortium’s  open  interoperability  framework  to  reach  across  the  internet  and  intranets  to  invoke 
processing  services  and  retrieve  data  from  other  GIS  applications.  The  system  can  also  be  configured  to  publish  data 
in  real-time  to  third-party  applications  via  WMS,  KML,  and  GeoRSS. 


7.7.2  For  this  experiment,  the  earthquake  shake  model  was  run  to  estimate  damage  in  the  region.  See  the  example 
output  below  from  the  9th  September  201 1  earthquake  off  Vancouver  Island. 


EmerGeo  Smart  Client:  Training  and  Simulation  (  Connected  to  Server  ^'Earthquake'  [Earthquake  Demo  Server]°)  Vancouver  -  Admin  |  mmorrow 
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Figure  13  -  EmerGeo  Smart  Client  -  shake  model  output  from  the  recent  6.4  earthquake 
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I.  Instrumental 

II.  Weak 


IV.  Moderate 


V.  Rather  Strong 


Generally  not  felt  by  people  unless  in  favorable  conditions. 

Felt  only  by  a  few  people  at  best,  especially  on  the  upper  floors  of  buildings.  Delicately 
suspended  objects  may  swing. 

Felt  quite  noticeably  by  people  indoors,  especially  on  the  upper  floors  of  buildings.  Many 
do  not  recognize  it  as  an  earthquake.  Standing  motor  cars  may  rock  slightly.  Vibration 
similar  to  the  passing  of  a  truck.  Duration  estimated. 

Felt  indoors  by  many  people,  outdoors  by  few  people  during  the  day.  At  night,  some 
awaken.  Dishes,  windows,  doors  disturbed:  walls  make  cracking  sound.  Sensation  like 
heavy  truck  striking  building.  Standing  motor  cars  rock  noticeably.  Dishes  and  windows 
rattle  alarmingly. 

Felt  outside  by  most,  may  not  be  felt  by  some  outside  in  non -favorable  conditions.  Dishes 
and  windows  may  break  and  large  bells  will  ring.  Vibrations  like  large  train  passing  close 
to  house. 

Felt  by  all:  many  frightened  and  run  outdoors,  walk  unsteadily.  Windows,  dishes, 
glassware  broken:  books  fall  off  shelves:  some  heavy  furniture  moved  or  overturned:  a  few 
instances  of  fallen  plaster.  Damage  slight. 

Difficult  to  stand:  furniture  broken:  damage  negligible  in  building  of  good  design  and 
construction:  slight  to  moderate  in  well-built  ordinary  structures:  considerable  damage  in 
poorly  built  or  badly  designed  structures:  some  chimneys  broken.  Noticed  by  people 
driving  motor  cars. 

Damage  slight  in  specially  designed  structures:  considerable  in  ordinary  substantial 
buildings  with  partial  collapse.  Damage  great  in  poorly  built  structures.  Fall  of  chimneys, 
factory  stacks,  columns,  monuments,  walls.  Heavy  furniture  moved. 


Figure  14  -  Modified  Mercalli  Index 


7.8  The  CAP/Atom  Scenario  Generator 

7.8.1  The  CAP/Atom  message  generator  tool  is  a  desktop  application  that  was  built  specifically  for  the  experiment  in 
C#/.net  using  a  SQLLite  database.  SQLLite  is  a  public  domain,  self-contained  library  that  provides  a  “zero- 
configuration”  transactional  SQL  database  engine.  The  .Net  code  runs  on  the  .Net  V4  library  and  provides  the  user 
interface  which  is  shown  in  Figure  15.  This  interface  allows  a  user  to  generate  Common  Alerting  Protocol  -  Canadian 
Profile  (CAP-CP)  messages  and/or  Atom-only  messages.  Atom  messages  are  used  for  sending  messages  that  are 
more  for  general  interest  and  were  not  used  in  the  experiment.  All  messages  generated  were  in  the  CAP-CP  format 
and  were  published  to  a  MASAS  hub  that  was  set  up  specifically  for  the  project  at  http://cause.masas.ca 

7.8.2  One  of  the  outputs  and  leave-behind  for  the  project  was  the  code  base  developed  for  this  product,  including  user 
and  technical  documentation.  This  product  has  already  been  put  to  use  by  EMBC  for  testing  and  training  purposes  on 
BCeMap  and  also  to  drive  scenarios  for  Operation  Nanook  (a  military  exercise  with  greater  than  500  personnel  being 
deployed  in  Resolute,  NU). 
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Figure  15  -  CAP/Atom  Scenario  Generator 


7.9  MASAS  and  CAP-CP 

7.9.1  The  national  MASAS  initiative  has  established  an  approach  and  technical  solution  for  sharing  authoritative, 
location-based  situational  awareness  information.  The  purpose  is  near  real  time  exchange,  within  Canada’s 
emergency  management  community,  and  across  the  border  with  American  colleagues. 

7.9.2  MASAS  adopts  a  system  of  systems  approach  -  connecting  many  disparate  systems  using  an  open  geospatial 
standard  (ATOM),  and  using  a  Canadian  version  of  the  Common  Alerting  Protocol  (CAP),  and  OASIS  standard.  The 
Canadian  version  is  essentially  a  defined  usage  profile  for  the  standard  CAP  messaging  structure  i.e.  mapping  of 
certain  attributes  to  defined  look  up  lists  for  event  types  and  geographic  areas  that  are  specific  to  Canada.  This  is 
called  the  CAP-Canadian  Profile,  or  CAP-CP. 

7.9.3  The  MASAS  NIT  have  provided  open  source  code  to  developers,  to  lower  the  barriers  to  adoption  and 
interoperability,  and  allow  message  generation  and  consumption  code  to  be  incorporated  in  other  systems. 

7.9.4  For  emergency  management  officials  without  their  own  application  infrastructure,  MASAS  offers  basic  web  hosted 
tools  for  posting  and  sharing  their  information  and  alerts. 

7.9.5  The  MASAS  NIT,  funded  and  guided  by  the  national  GeoConnections  Program  in  concert  with  the  CSS,  continues 
its’  efforts  to  build  an  enduring  national  capability,  in  alignment  with  the  Communications  Interoperability  Strategy  and 
Action  Plan  for  Canada  2. 

7.9.6  Development  and  operationalization  funding  for  MASAS  has  been  secured  until  2013  via  CSS  and  NRCan,  with 
support  and  collaboration  from  Public  Safety  Canada. 

7.9.7  Uptake  of  MASAS  and  CAP-CP  is  accelerating.  MASAS  has  seen  limited  use  in  real  emergency  operations  (e.g. 
to  support  Manitoba  floods).  Core  infrastructure  and  supporting  tools  have  been  developed,  tested,  piloted  and  used 
in  real  operations. 

7.9.8  Options  analysis  is  underway  for  the  development  of  an  operational  business  model  and  components  that  will  be 
fed  into  a  broader  policy  development  cycle  for  consideration  by  the  federal  partners  and  our  Federal  Provincial  and 
Territorial  partners  via  Senior  Officials  Responsible  for  Emergency  Management  (SOREM).  Federal  government  is 
expected  to  continue  to  have  a  strong  role  in  leadership  on  MASAS,  but  the  day-to-day  operating  model  is  still  under 
development. 

7.9.9  MASAS  is  currently  designed  for  emergency  management  officials  only.  No  public  access  is  currently  provided, 

2  http://www.publicsafetv.qc.ca/pra/em/cisapc-scicpa-eng.aspx 


Page  30 


CAUSE  Resiliency  West  Coast  Final  report  v17  dh  edits. docx 


but  publicly-sourced  'open'  data  feeds  and  common  operational  datasets  can  be  brought  in  provided  they  are  trusted 
authoritative  sources  (BC  River  Forecast  is  an  example).  In  addition  the  longer  term  future  of  MASAS  may  include 
interfaces  with  public  alerting  infrastructure  (e.g.  interoperation  with  e  National  Alert  Aggregation  and  Dissemination. 


7. 10  The  MASAS  CAUSE  Hub  and  Related  Tools 

7.10.1  A  MASAS  hub  was  set  up  and  hosted  at  Simon  Fraser  University  (SFU)  specifically  for  the  purpose  of  supporting 
the  experiment  at  http://cause.masas.ca  (Note  that  as  this  is  a  temporary  site  and  no  sensitive  information  was  used 
in  the  experiment;  a  Secure  Sockets  Layer  (SSL)  certificate  was  not  used  (i.e.  it  was  not  an  https  site)). 

7.10.2  User  Administration:  The  MASAS  hub  tool  set  comes  with  a  simple  on-line  access  management  tool  that 
generates  the  ‘secret’  text  string  used  to  grant  access.  It  is  appreciated  that  this  is  not  the  long  term  security  model, 
however  it  is  currently  easy  to  administer,  and  combined  with  SSL  encryption,  effectively  secures  the  hub. 

MASAS  -  CAUSE  -  User  Service 


User  List 


Add  User 


Name^ 

Paul  Childs 

Gary  Li 

James  Galbraith 

CAUSE  observe 

DougAUport 

MyStateUSA 

SAMapper 

TvRCan  Earthquakes  Canada 

IPAWS  Connection 

KrisHayne 


Logout 

Description^ 

IT  Consultant  managing  CAUSE  project 
CAUSE  test  pack  developer 
Planetworks  consultant 
Observers  for  the  experiment 

Account  for  MyStateUSA  to  create  events  on  MASAS  Hub 

NRCan  Earthquakes  Canada  feed 
IPAWS  Connection  Account 
EMBC  Business  Area  Expert 


Email  List  (save  as  .csv) 


MASAS 

7.10.3  Viewer  Tool  -  The  MASAS  viewer  tool  allows  users  to  view  alerts  that  are  active  on  the  hub,  including  the  ability 
to  zoom  and  pan  using  the  map  display  to  focus  in  on  areas  of  interest,  as  well  as  providing  some  basic  filtering 
capabilities.  A  sample  of  the  viewer  tool  as  used  in  the  201 1  Manitoba  flooding  is  shown  in  Figure  16. 
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Figure  16  -  Viewing  Tool  Example-  Manitoba  Flooding 


7.10.4  Posting  tool  -  the  MASAS  posting  tool  is  an  online  interface  that  also  allows  CAP-CP  and  Atom  Entry  records  to 
be  created  and  updated.  The  scenario  generator  was  used  for  most  of  the  experiment  to  create  messages  in  the 
experiment,  however  the  online  posting  tool  was  used  extensively  to  expire  test  messages  and  remove  them 
effectively  from  the  viewers  connected  to  the  hub  prior  to  each  experimental  run  (due  to  lack  of  update  functionality  in 
the  message  generator  tool).  See  Figure  17. 


Figure  17  -  MASAS  Posting  Tool 


7.11  MASAS  ESRI  Flex  Tools  (MEFT) 

7.11.1  Another  viewing  tool  used  in  the  experiment  for  observers  was  a  demonstration  version  of  the  MASAS  ESRI  Flex 


Page  32 


CAUSE  Resiliency  West  Coast  Final  report  v17  dh  edits.docx 


2.3  viewer,  developed  by  the  CSS  and  hosted  by  SFU  at  the  following  url:  http://masas3.trl.sfu.ca/MEFT/ 

7.11.2  This  site  allowed  observers  to  follow  the  “action”  for  each  of  the  vignettes,  but  was  used  primarily  for  the  briefing 
and  regional  overview  sessions  held  in  the  morning  on  the  dry  run  and  execution  date.  See  Figure  18. 

7.11.3  The  MEFT  tools  are  available  as  open  source  code  for  use  in  any  implementation  of  an  ESRI  Flex  map 
presentation  system,  allowing  MASAS  events  to  be  consumed  (as  used  in  this  experiment)  and  published  also. 


Figure  18  -MASAS  ESRI  Flex  Tool  (MEFT) 

7.12  SAMapper 

7.12.1  One  of  the  systems  implemented  for  the  experiment  by  the  PNNL  team  was  a  product  called  Situational 
Awareness  Mapper  (SAMapper).  This  was  developed  from  a  Graffiti  tracking  tool  developed  with  police  forces  in 
mind  for  recording  and  tagging  graffiti  instances  with  the  gang  identifiers  in  a  dashboard  system.  It  was  re-purposed 
and  renamed  for  the  experiment  to  allow  mobile  users  to  use  a  handheld  PDA  to  take  a  picture  of  infrastructure 
damage  and  tag  the  record  with  the  damage  type  and  severity  and  for  this  to  be  pushed  to  the  dashboard  application 
hosted  on  Google  Apps. 

7.12.2  The  hosted  url  was  made  available  at  http://samapper.appspot.com/SaMap.isp.  and  did  not  require  a  login  ID  or 
password  (i.e.  account  or  role  based  security  was  not  implemented). 

7.12.3  A  copy  of  the  code  for  installing  the  mobile  application  was  made  available  to  the  Canadian  project  and  was 
installed  and  used  during  the  experiment  to  demonstrate  capture  and  coding  of  a  picture,  pushing  the  picture  to  the 
dashboard  and  subsequently  to  MASAS  and  BCeMap  (to  prove  the  international  interconnection  feasibility). 

7.12.4  The  dashboard  presentation  of  the  application  is  illustrated  in  Figure  19. 
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Figure  19  -  SAMapper 


7.13  MyStateUSA 

7.13.1  MyStateUSA  is  a  company  that  develops  alerting  products  including  CAP-compliant  emergency  alerting,  public 
notification,  content  sharing  and  interoperability,  focusing  on  community,  campus,  business  and  governmental 
agencies. 

7.13.2  MyStateUSA  is  used  by  the  Washington  State  Emergency  Management  Department  for  alert  management  and 
interoperation  with  DM  Open  and  I  PAWS.  A  screenshot  from  the  MyStateUSA  messaging  console  is  included  in 
Figure  20. 


'  mystateusa.com 


System  console 

Jurisdiction  Name:  Washington  Emergency  Management  (672) 
Signed  in  as:  eiones  (Elysa  Jones) 


Figure  20  -  MyStateUSA  emergency  message  system  console 
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7.14  I  PAWS 


7.14.1  In  the  United  States,  an  executive  order  established  the  requirement  for  an  “effective,  reliable,  integrated,  flexible, 
and  comprehensive  system  to  alert  and  warn  the  American  people”.  FEMA  was  designated  within  the  Department  of 
Homeland  Security  to  implement  policy  and  establish  a  program  office  to  implement  an  Integrated  Public  Alert 
Warning  System  (IPAWS).  More  detail  on  the  IPAWS  program  is  available  via 
http://www.fema.gov/emergency/ipaws/. 


7.14.2  The  IPAWS  Open  Platform  for  Emergency  Networks  (OPEN)  consists  of  a  set  of  securely  hosted  Web  services 
that  enable  the  routing  of  standards-compliant  emergency  messages  between  third-party  applications,  systems, 
networks  and  devices.  Since  the  initial  version  of  OPEN  (DM-OPEN  1.0)  had  an  established  capability  to  route  CAP 
alerts  between  organizations  and  to  the  public  via  the  National  Weather  Service’s  (NWS)  All-Hazards  Emergency 
Message  Collection  System  (HazCollect),  OPEN  was  selected  by  FEMA  to  perform  message  aggregation  for  IPAWS. 

7.14.3  The  diagram  in  Figure  21 3  has  at  its  core  a  message  router,  OPEN,  which  routes  alerting  messages  between 
alerting  authorities  (similar  to  MASAS  but  using  a  more  specific  addressing  scheme)  and  also  to  the  public  through 
the  public  alerting  systems  (a  role  that  is  not  currently  fulfilled  by  MASAS). 


IPAWS  Architecture 

Standards  Based  Alert  Message  protocols,  authenticated  alert  message  senders,  shared,  trusted  access 
&  distribution  networks,  alerts  delivered  to  more  public  interface  devices 
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Figure  21  -  IPAWS  Architecture 


7.14.4  IPAWS-OPEN  enables  the  interoperable  sharing  of  emergency  alerts  and  incident-related  data  between  systems 
that  comply  with  non-proprietary  information  standards,  and  serves  as  the  message  aggregator  for  the  Integrated 
Public  Alert  and  Warning  System.  IPAWS-OPEN  2.0  supersedes  the  existing  DM-OPEN  which  was  scheduled  for 
decommissioning  by  June  30,  201 1 . 


3  http://www.fema.gov/pdf/emerqencv/ipaws/architecture  diaqram.pdf 
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7.14.5  Several  private  and  public  sector  software  developers  have  executed  Memorandum  of  Agreements  with  FEMA  in 
order  to  access  the  IPAWS-OPEN  test  environment.  A  listing  is  available  in  Adobe  PDF  format  from 
http://www.fema.aov/pdf/emergencv/ipaws/open  developers.pdf  (this  list  includes  MyStateUSA). 


7.15  AMECom  Truck 

7.15.1  The  SFU  Advanced  Mobile  Emergency  Communications  (AMECom)  project  is  intended  to  address  the  short  term 
needs  of  many  communities  in  BC  that  will  potentially  arise  due  to  hazards  that  destroy  local  communication 
infrastructures. 


7.15.2  The  AMECom  truck  has  been  developed  to  meet  this  need  and  has  an  advanced  set  of  communication 
capabilities.  It  can  be  quickly  moved  into  place  and  activated  to  support  local  communities,  provide  voice  and  data 
services,  provide  communications  for  Emergency  Operations  and  provide  interoperation  between  disparate  agencies 
radio  systems. 


7.15.3  The  truck  is  a  prototype  and  test  bed  for  integrating  different  communication  systems  (from  satellite,  to 
microwave,  and  land  mobile  radio)  and  has  already  seen  operation  use  at  the  request  of  the  Provincial  Emergency 
Management  organisations. 


Figure  22  -  AMECom  truck 
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8.  Vignettel :  The  Story  from  Richmond  Emergency  Management  -  Before  the 
Event 


8.1  Vignette  1:  Introduction 

8.1 .1  Emergency  management  personnel  are  constantly  planning  for  all  eventualities,  except  for  those  times  when  they 
are  actively  responding  to  real  emergencies  and  incidents  in  their  jurisdiction.  An  earthquake  in  the  Cascadian 
subduction  zone  is  an  example  of  one  such  potential  eventuality  that  is  revisited  periodically  to  refresh  the 
understanding  of  characteristics  of  such  an  event,  it’s  possible  short  and  long  term  effects,  and  the  operational 
response  structures  and  procedures  as  these  continue  to  develop  and  evolve. 

8.1.2  Tools  are  becoming  available  that  help  with  theses  periodic  assessments  making  the  planners’  jobs  easier  in 
terms  of  presenting  tangible  information  on  threats  and  potential  damage. 

8.1.3  This  vignette  is  designed  using  models,  developed  for  the  City  of  Richmond,  in  a  tool  called  Hazus-MH.  The 
models,  developed  to  be  specific  to  the  municipality,  are  used  to  help  understand  the  threat  and  level  of  damage  that 
may  result  from  such  an  earthquake.  The  work  to  develop  such  models  was  performed  in  partnership  with  Natural 
Resources  Canada  (NRCan),  which  is  developing  an  integrated  risk  assessment  methodology  for  Canada  as  well  as 
piloting  the  employment  of  Hazus-MH  in  various  communities  in  BC.  NRCan  is  also  developing  baseline  data  sets  for 
broader  areas  such  as  Metro  Vancouver  (which  encompasses  multiple  municipalities,  including  Richmond). 

8.1.4  The  models’  output  includes  various  damage  assessments,  such  as  loss  of  buildings,  damage  to  critical 
infrastructure,  loss  of  life,  injuries  and  debris  produced. 

8.1.5  In  this  vignette,  NRCan  and  City  of  Richmond  staff  work  together  to  run  scenarios,  generating  several  damage 
assessment  reports  and  discussing  these  with  the  seismic  specialist  at  EMBC  in  order  to  determine  whether  the 
models  are  valid,  consistent  with  accepted/standard  methodology  and  whether  they  can  be  lodged  for  planning 
purposes  in  a  provincial  library.  Such  a  library  does  not  currently  exist  but  might  host  the  output  of  a  number  of 
threats,  hazards  and  damage  assessment,  for  various  municipalities,  for  presentation  through  a  tool  such  as  BCeMap. 

8.1.6  The  vignette  therefore  also  explores  a  means  of  storing  the  damage  assessment  outputs  as  static  layers  in 
BCeMap  to  be  used  in  a  later  vignette. 

8.2  Vignette  1:  The  Technology  Integrations 

8.2.1  For  this  vignette  the  Hazus-MH  tool  was  furnished  and  supported  by  an  NRCan  project,  managed  by  the 
Geological  Survey  of  Canada,  Earth  Sciences  Sector.  This  project  is  described  in  more  detail  in  section  6.3 

8.2.2  The  data  sources  and  flows  that  were  used  to  support  this  vignette  are  illustrated  in  Figure  23.  The  Building 
Inventory  and  the  Richmond  specific  sources  are  greyed  out  as  these  were  not  enabled  in  the  experiment;  however  if 
available  they  could  be  used  to  augment  the  information  coming  from  the  other  sources  and  would  provide  greater 
accuracy  and  detail  in  the  damage  assessments. 

8.2.3  The  NRCan  project  has  developed  a  source  database  called  the  Asset  Inventory  Management  System  (AIMS), 
which  is  pre-populated  by  information  from  Statistics  Canada  (e.g.  population  and  demographics),  The  Provincial 
Terrain  Resources  Inventory  Mapping  (TRIM)  data,  which  includes  water  features,  roads,  point  data  such  as  bridges, 
tunnels  and  some  point  assets,  GeoBC4  municipal  data  (some  asset  information  collected  by  GeoBC  for  emergency 
management  purposes)  and  BC  Assessment  data  (containing  building  location,  value  and  usage  information). 

8.2.4  These  inputs  were  used  in  the  vignette  to  generate  some  basic  outputs  (called  Hazus  Level  1  outputs)  as  a 
starting  point  to  allow  the  City  of  Richmond  Emergency  Management  team  to  appreciate  the  capability. 


4  Subsequent  to  this  project  GeoBC  has  been  restructured  into  a  number  of  different  ministries  including  Citizens 
Services.  For  the  purposes  of  this  report  the  term  GeoBC  continues  to  be  used. 


Page  37 


CAUSE  Resiliency  West  Coast  Final  report  v17  dh  edits. docx 


Figure  23  -  Hazus-MH  integration 


8.2.5  Given  the  time  available  for  the  project,  it  was  not  possible  to  add  any  Richmond-specific  asset  data  (e.g.  critical 
infrastructure  facilities),  nor  was  it  possible  to  clear  the  permissions  required  to  obtain  the  building  inventory  data 
collected  by  UBC  (which  would  provide  a  finer  level  of  detail  on  the  damage  by  block  and  census  tract,  i.e.  Hazus 
Level  2). 

8.2.6  However  it  was  possible  to  run  preliminary  Level  1  damage  assessments  for  the  municipality  with  the  following 
outputs: 


•  Total  Debris  in  tons  per  Census  Track 

•  Total  Wood  &  Brick  Debris  in  tons 

•  Total  Concrete  and  Steel  Debris  in  tons 

•  Number  of  Truckloads  required  based  on  calculation:  Total  Debris  in  tons  per  Census  Track 

•  /  25  Tons  per  truck 

•  Total  building  damage  loss  per  tract  in  Thousands  of  Dollars  (does  not  include  building  content 
amount) 

8.2.7  These  damage  assessments  were  produced  in  the  context  of  the  earthquake  scenario  used  in  this  experiment, 
which  is  a  threat  model  currently  supported  by  parameters  in  the  Hazus-MH  system,  based  on  the  USGS  scenario 
referenced  in  section  5.6. 

8.2.8  Hazus-MH  can  produce  numerous  other  outputs  including  projected  injuries  and  deaths,  however  considering  the 
preliminary  nature  of  these  outputs  (i.e.  not  validated)  and  the  potential  sensitivities  in  the  city  to  such  information, 
especially  if  used  in  the  film  output,  these  were  avoided  at  this  point. 
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8.2.9  The  outputs  were  saved  to  shape  files  (.shp)  and  then  sent  to  NRCan  to  be  hosted  on  Mapserver5  servers  in 
Ottawa  to  provide  the  WMS  output  for  consumption  in  BCeMap.  BCeMap  was  able  to  consume  and  present  the  WMS 
layers  relatively  easily  (it  required  an  hour’s  work  to  determine  the  mime-type  and  configure  the  layers  on  BCeMap). 

8.3  Vignette  1:  The  Action 

8.3.1  A  normal  office  environment  was  simulated  at  the  Richmond  film  location.  The  action  and  dialogue  was  carried 
out  between  the  city  emergency  management  staff  and  NRCan  consultants,  discussing  the  inputs  to  the  model,  the 
quality  or  state  of  the  developed  data,  and  the  potential  outputs.  The  outputs  were  also  discussed  with  the  Provincial 
Seismic  Specialist.  Conceptually,  if  all  municipalities  were  to  perform  the  same  analysis,  this  information  could  be 
aggregated  and  it  would  be  apparent  where  the  most  damage  might  occur,  supporting  the  ability  to  prioritize  the 
recovery  process  according  to  need.  Some  samples  of  the  outputs  are  shown  below. 


Figure  24  -  Debris  Total  Per  Tract 
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Figure  25  -  Number  of  Truckloads  Required 


Figure  26  -  Building  Damage  Loss 
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8.3.2  The  outputs  above  would  be  available  via  printed  or  file  outputs  from  the  Hazus-MH  tool,  which  would 
conceptually  be  hosted  and  managed  in  this  context  by  the  City  of  Richmond  (in  order  to  protect  any  city-specific 
critical  infrastructure  data  that  is  entered  into  the  system).  The  problem  then  becomes  one  of  managing  the  file 
outputs  from  both  a  city  and  Provincial  perspective,  i.e.  how  are  these  files  to  be  stored  and  archived  by  threat 
scenario  and  made  readily  available  locally  or  provincially  (with  an  ability  to  compare  and  contrast  different 
municipalities)?  One  option  is  to  register  the  output  files  as  layers  in  BCeMap  such  that  they  can  be  turned  on  and  off 
by  threat,  by  damage  type  and  by  municipality.  This  was  implemented  for  Richmond  for  the  experiment  as  described 
above  and  illustrated  below  i.e.  as  layers  in  BCeMap. 
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Figure  27  -  Total  Debris  Per  Tract 
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Figure  28  -  Total  Trucks  Needed 


Figure  29  -  Total  Building  Loss 
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8.4  Experimental  Findings  from  the  Vignette 

8.4.1  In  general,  the  Hazus-MH  tool  was  well  received  and  deemed  useful  by  the  City  of  Richmond  Emergency 
Management  team,  contributing  to  the  goal  of  being  able  to  develop  a  better  understanding  of  the  potential  effect  of 
different  scenarios. 

8.4.2  It  was  felt  that  a  fully  developed  model  with  trusted  inputs  could  be  valuable  in  modeling  and  planning  for  various 
scenarios.  There  are,  however,  concerns  around  the  costs,  in  terms  of  time  and  effort,  that  could  be  incurred  to 
develop  and  maintain  an  accurate  database  of  inputs  (including  assets  and  critical  infrastructure),  as  well  as  concerns 
as  to  how  much  faith  could  be  placed  in  the  output.  One  significant  concern  relates  to  the  requirement  to  validate  the 
science  behind  the  soil  type  data  chosen  for  the  model,  as  this  input  would  have  a  significant  impact  on  the  outputs, 
particularly  for  Richmond  which  is  on  a  flood  plain  surrounded  by  dykes. 

8.4.3  Whether  Hazus-MH  could  be  of  benefit  as  a  potential  repository  of  Critical  Infrastructure  information  was 
discussed  i.e.  consolidation  in  a  single  system  as  opposed  to  being  maintained  across  a  number  of  files  as  is  currently 
the  case.  Presentation  could  be  enabled  in  the  Emergency  Operations  Centre  through  projection  on  a  large  screen 
with  suitable  user  access  to  the  software.  There  would;  however,  be  limitations  for  multi-user  access  and  for  different 
users  requirement  (the  need  to  see  information  at  different  times),  as  Hazus-MH  was  essentially  designed  as  software 
for  a  single  personal  computer.  It  would  therefore  not  easily  support  the  concept  of  a  virtual  operations  centre  that  is 
being  considered  by  the  City  of  Richmond.  (An  inherent  requirement  being  provision  of  support  for  remote  users 
having  access  to  the  information.) 

8.4.4  Another  concern  expressed  related  to  the  potential  for  Hazus  models  to  be  used  to  determine  the  relative  possible 
damage  in  each  municipality,  and  to  then  employ  those  models  to  determine  priorities  and/or  allocate  resources  at  the 
provincial  level.  It  was  felt  that  this  was  a  somewhat  dangerous  proposition  and  that  its  real  value  lies  in  supporting 
municipal  assessments  and  requests  for  resources  and  state  why  they  need  it,  and  for  decisions  to  be  made  on  this 
basis  rather  than  on  theoretical  models  and  computer  generated  information. 

8.4.5  If  or  when  BCeMap  is  rolled  out  to  municipalities,  it  would  be  possible  to  enter  Richmond-specific  data  layers  into 
BCeMap  which  could  be  secured  by  the  BCeMap  security  gateway  so  as  to  be  only  accessible  to  Richmond 
personnel.  The  information  could  be  mastered  locally  e.g.  in  something  like  Hazus  and  then  served  up  “in  the  cloud” 
through  BCeMap,  if  that  was  deemed  to  be  an  appropriate  mechanism  (i.e.  if  the  security  concerns  of  having  the 
information  hosted  outside  of  the  Richmond  jurisdiction  infrastructure  were  overcome). 

8.4.6  For  the  damage  assessment  layer  output  from  Hazus-MH,  as  can  be  seen  from  the  figures  above,  the 
presentation  in  BCeMap  is  very  similar  to  that  possible  in  Hazus.  However  the  one  item  missing  in  the  experimental 
implementation  is  the  class  descriptors  for  the  various  colours.  In  Figure  6  the  WMS  “identify”  function  has  been  used 
to  show  the  data  available  from  the  Mapserv  service,  but  this  function  is  not  viewed  as  being  very  useful.  Further 
investigation  will  be  needed  to  see  if  the  WMS  can  deliver  this  information  if  determined  to  be  required.  The  second 
potential  limitation  is  the  need  for  these  files  to  be  supported  by  the  thematic  layers  menu  hierarchy,  which,  though 
effective  for  even  significant  numbers  of  layers,  may  prove  problematic  if  there  are  20  or  more  damage  layers  per 
threat  scenario,  multiple  threat  scenarios  (which  may  need  to  be  indexed  and  referenced  with  descriptive  data)  and 
multiple  municipalities  hosted  on  the  system.  A  simple  menu  hierarch  may  not  be  sufficient  and  a  slightly  more 
sophisticated  user  interface  would  need  to  be  considered. 

8.4.7  It  is  understood  that  NRCan  is  also  pursuing  projects  to  develop  the  potential  presentation  of  Hazus  outputs  in 
more  useable  formats:  namely  though  an  adapter  to  an  ArcGIS  add-on  tool  called  CommunityViz  Scenario3605,  and 
also  through  a  project  through  a  contract  placed  with  Galdos  Systems  Inc.  to  develop  an  online  registry  of  Hazus 
model  output  layers.  Neither  of  these  projects  was  developed  sufficiently  to  be  included  in  the  CAUSE  experiment  this 
year. 

8.4.8  During  the  experiment  it  was  discovered  that  Hazus-MH  is  only  one  of  a  set  of  tools  in  use  by  the  USGS  and 
FEMA  in  the  United  States  for  planning  and  provision  of  early  warnings  or  models  of  Seismic  events.  There  are  also 
a  number  of  tools  that  are  dynamically  linked  to  the  automatic  output  of  the  USGS  seismic  sensors  that  could  be  used 
in  the  immediate  aftermath  of  a  major  earthquake  in  advance  of  the  use  of  Hazus-MH  to  provide  detailed  model 
outputs  somewhat  after  the  event. 

8.4.9  The  following  skeleton  timeline  and  list  of  tools  was  provided  by  NRCan  as  part  of  their  investigations  with  US 
counterparts  relating  to  their  projects.  The  USGS  real-time  earthquake  feed  would  trigger  two  outputs,  the  first  is  the 
pager  output,  which  is  essentially  a  broadcast  information  sheet  on  population  impacts  and  includes  Shakemaps. 


5  http://placeways.com/products/index.php 
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There  is  also  a  Shakecast  application  that  can  be  implemented  by  any  organization  using  free  software.  It  allows  a 
subset  of  the  Hazus  models  to  be  run  in  real  time  off  the  USGS  real-time  feed  and  supports  rapid  impact 
assessments.  There  was  insufficient  time  to  evaluate  or  trial  this  application  as  part  of  the  CAUSE  experiment; 
however,  these  tools  could  work  off  the  same  baseline  data  sets  at  Hazus  and  would  therefore  be  of  incremental 
value  on  top  of  those  data  sets  if  implemented. 


Scenario  timeline 


Figure  30  -  Other  Seismic  Warning  and  Analysis  Tools 


8.5  Vignette  Recommendations 

8.5.1  Based  on  the  findings  above  it  is  recommended  that  the  City  of  Richmond  investigate  incorporation  of  Hazus-MH 
into  their  tool  set  for  evaluating  potential  damage  during  various  threat  scenarios  and  storing  the  output  for  planning 
and  analysis  purposes.  Follow-on  work  includes  upgrading  the  soils  data  files,  adding  the  building  inventory  data  sets 
as  produced  by  UBC  and  inputting  Richmond-specific  critical  infrastructure  data.  This  would  place  the  city  at  the 
forefront  of  municipal  hazard  analysis  in  Canada,  matched  only  by  North  Vancouver  and  Squamish  (other  participants 
in  the  NRCan  pilot  projects).  However  the  resource  required  to  build  and  maintain  accurate  models  should  not  be 
underestimated. 

8.5.2  Additional  work  is  underway  through  the  NRCan  projects  to  develop  the  data  sources  for  AIMS,  including 
enhancing  sources  of  data  and  providing  the  access  mechanisms  to  the  AIMS  data  for  municipalities  as  the 
information  is  updated.  As  part  of  this  a  long  term  hosting/service  solution  is  required  for  AIMS  which  may  require 
provincial  support. 

8.5.3  Further  investigation  is  required  into  defining  requirements  for  an  appropriate  mechanism  for  storing  the  library  of 
threats  and  related  damage  assessments  output  by  each  municipality,  based  on  who  would  need  access  to  these  and 
for  what  purpose.  Local  decision  makers  and  planners  certainly  need  access,  potentially  remotely  if  the  Virtual 
Emergency  Operations  Centre  concept  is  in  place,  however  there  may  be  benefit  in  regional  or  provincial  access.  A 
further  objective  of  future  CAUSE  experiments  could  explore  the  requirements  and  the  alternatives  further  i.e.  the 
requirements  and  outputs  of  the  CommunityViz  and  Galdos  projects 

8.5.4  Since  the  Hazus  modules  use  very  similar  data  to  that  used  by  the  USGS  Shakecast  tool  which  can  provide  a 
short  term  and  high  level  assessment  of  damage  in  the  case  of  a  live  event,  it  is  recommended  that  Shakecast  is 
evaluated  to  understand  if  additional  benefit  can  be  leveraged  from  the  data  collation  undertaken  for  Hazus.  This 
again  could  be  part  of  a  future  experiment. 
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8.5.5  Development  of  a  provincial  framework,  in  partnership  with  NRCan  for  providing  additional  support  to 
municipalities  may  also  be  required.  This  may  take  the  form  of: 

•  a  framework  for  collaboration  and  pooling  of  resources  if  there  is  insufficient  resource  at  a  local  level 

•  assistance  with  developing  an  understanding  and  expertise  in  science  to  allow  trust  in  the  outputs  that  are 
developed 

•  support  for  developing  a  range  of  threat  scenarios  that  can  be  used  by  municipalities  and  tailored  for  local 
circumstances 
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9.  Vignette  2:  Richmond  EOC  Activation  and  Situation  Assessment 


9. 1  Vignette  2:  Introduction 

9.1.1  This  vignette  is  based  on  the  activation  of  the  City  of  Richmond  EOC  and  the  initial  briefings  as  staff  arrive  using 
EmerGeo  Fusionpoint  as  the  incident  management  system  and  employing  the  EmerGeo  Smart  Client  to  assess  the 
potential  ground  shake  effects  in  Richmond  as  reports  come  in  of  damage  to  the  city. 

9.1.2  Fusionpoint  was  implemented  as  a  hosted  system  so  as  to  allow  remote  decision  makers  to  access  the  software, 
and  dialogue  was  enacted  with  remote  users  with  the  Fusionpoint  incident  records  and  maps  as  context  for  the 
discussions. 

9.1.3  As  the  story  unfolds  of  incidents  in  Richmond,  the  vignette  develops  to  the  point  where  a  dialogue  is  conducted 
between  Richmond  EOC  and  the  South  West  PREOC.  This  includes  a  briefing  based  on  the  incidents  recorded  in 
EmerGeo  Fusionpoint  and  a  representation  of  those  incidents  communicated  to  the  SW  PREOC  through  BCeMap. 
The  discussion  also  covers  the  need  for  communications  support  at  Richmond  City  hall  due  to  intermittent  internet 
connectivity  which  is  limiting  data  communications  and  a  request  for  the  AMECom  truck  for  this  purpose.  At  the  South 
West  PREOC  the  damage  assessment  model  output  from  Hazus-MH  was  also  selected  in  conjunction  with  the 
provincial  seismic  expert. 

9.1.4  In  reality  such  communications  between  the  City  of  Richmond  and  SWPREOC  would  be  managed  through 
situation  reports  and  formal  resource  requests;  however,  the  interaction  was  dramatized  for  purposes  of  illustration. 

9.2  Vignette  2:  The  Technologies 

9.2.1  The  vignette  involves  use  of  EmerGeo  Fusionpoint  which  is  described  in  section  6.6.  This  was  set  up  and  hosted 
by  EmerGeo  for  the  purposes  of  the  experiment.  The  main  features  of  the  product  exercised  were  the  links  to  traffic 
cameras,  the  incident  capture  screens  and  the  map  representation  of  the  city. 

9.2.2  Both  Richmond  EOC  members  and  remote  users  were  able  to  access  the  application  remotely  by  means  of  a 
browser.  More  could  have  been  made  of  this  capability  in  the  experiment,  for  example  by  engaging  a  decision  maker 
in  the  process;  however,  the  vignette  limited  utilization  to  acting  out  the  possibility. 

9.2.3  A  WMS  feed  was  set-up  on  the  application  to  publish  the  incidents  captured  in  the  system  for  consumption  in 
BCeMap  to  support  the  dialogue  with  the  SW  PREOC. 

9.2.4  The  EmerGeo  Smart  Client  was  fed  by  an  alert  that  could  have  been  published  by  USGS  describing  the  location, 
magnitude  and  depth  of  the  Earthquake.  The  simulated  input  for  the  vignette  was  pulled  from  a  library  of  published 
USGS  events. 

9.2.5  Traffic  cameras  were  also  configured  to  be  accessible  to  the  users  through  the  Fusionpoint  portal  for  use  in  the 
experiment. 

9.2.6  These  configurations  are  illustrated  in  Figure  31 . 

9.2.7  The  deployment  of  the  AMECom  truck  and  a  tactical  communications  kit  was  discussed  as  part  of  the  dialogue, 
and  the  deployment  of  the  AMECom  truck  to  Vancouver  airport  was  simulated  but  not  actually  implemented  as  part  of 
the  project  because  of  scheduling  conflicts. 
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Figure  31  -  EmerGeo  Fusionpoint  and  Smart  Client 


9.3  Vignette  2:  The  Action 

9.3.1  The  vignette  starts  with  the  arrival  of  EOC  staff  and  a  general  briefing  from  the  Experiment  Coordinator  and  the 
EOC  Director  to  set  the  scene  and  describe  incidents  to  date.  This  included  a  general  information  update  regarding 
inputs  from  other  systems  and  neighbouring  jurisdictions  and  illustrations  using  the  Message  Generator,  MASAS  and 
BCeMap.  This  briefing  included  the  earthquake  location,  magnitude  and  aftershocks,  tsunami  alerts,  including  one  for 
the  Strait  of  Georgia  indicating  wave  heights  at  peak  of  0.5  metres  (not  a  concern  to  Richmond  dykes);  also  seismic 
sensor  readings  and  bridge  sensors  readings  on  the  bridge  structures  including  damage  to  the  Annacis  Channel 
Bridge  and  on-ramps,  resultant  congestion  on  the  Alex  Fraser  bridge.  Detail  on  these  inputs  is  included  in  a  later 
vignette  (as  they  were  not  a  focus  for  this  one). 

9.3.2  The  EOC  Director  then  hands  over  for  a  briefing  from  the  EOC  GIS  expert. 

9.3.3  The  first  local  incident  reported  is  the  closure  of  the  Massey  Tunnel  (input  from  the  municipality  of  Delta)  due  to 
liquefaction  and  confirmed  via  the  ability  to  see  camera  images  of  the  congestion  as  a  result  (see  Figure  32).  The 
incident  details  were  presented  as  in  Figure  33.  These  screenshots  are  taken  from  EmerGeo  Fusionpoint. 
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Figure  32  -  Massey  Tunney  Traffic  Cameras 


Figure  33  -  Massey  Tunnel  closed  incident  details 

9.3.4  A  major  gas  fire  was  also  reported  and  captured  as  an  incident  (see  the  log  entry  in  Figure  34). 
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Figure  34  -  Incident  Entry  Log 

9.3.5  This  was  then  visible  on  the  dashboard  map  in  Figure  35  along  with  other  earthquake  related  fires  and  also  visible 
to  local  EOC  staff  and  remote  Richmond  decisions  makers  on  the  large  situation  map  in  Figure  36. 
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Figure  35  -  Richmond  Incidents 
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Figure  36  -  North  Richmond  Large  Map  Overview 


9.3.6  The  GIS  expert  also  presented  Shakemaps  generated  using  the  EmerGeo  Smart  client  application  which  is  able 
to  create  maps  of  ground  motion  (shaking  intensity)  models  based  on  the  USGS  earthquake  feed  input  and  soils 
models  for  the  region.  The  two  examples  below  depict  different  view/zoom  levels  and  illustrate  Modified  Mercalli 
Intensity  scale  (MMI6)  value  =  4.5  (MODERATE  SHAKING)  and  Peak  Ground  Acceleration  (PGA7)  =  .03  (LIGHT 
SHAKING  AND  NO  DAMAGE  EXPECTED)  instances. 
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Figure  37  -  EmerGeo  smart  client  map  -  regional 


6  http://en.wikipedia.org/wiki/Mercalli  intensity  scale 

7  http://en.wikipedia.org/wiki/Peak_ground_acceleration 
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Figure  38  -  EmerGeo  smart  client  map  -  local 

9.3.7  In  the  vignette,  the  dialogue  with  the  SWPREOC  involved  a  general  briefing,  i.e.  an  exchange  to  and  from  the 
Richmond  EOC  with  the  BCeMap  representation  of  the  EmerGeo  Fusionpoint’s  incidents  visible  at  the  SWPREOC 
providing  context  for  the  discussion. 

9.3.8  The  WMS  feed  of  EmerGeo  as  presented  in  BCeMap  incidents  can  be  seen  in  Figure  39. 


Figure  39  -  EmerGeo  Fusionpoint  Incidents  in  BCeMap 
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9.3.9  Also  included  as  part  of  the  dialogue  at  the  SW  PREOC  was  a  discussion  with  the  Provincial  Seismic  advisor 
regarding  the  selection  and  display  of  an  appropriate  damage  assessment  model  from  Hazus  that  could  be  displayed, 
indicating  the  level  of  damage  in  Richmond  for  this  event. 
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9.4  Vignette  2:  Experimental  Findings 

9.4.1  The  City  of  Richmond  has  been  considering  implementing  a  Virtual  Emergency  Operations  centre  concept,  and 
the  chance  to  experiment  with  a  hosted  version  of  EmerGeo  was  welcomed.  It  offered  an  opportunity  to  explore  the 
benefits  of  a  virtual  incident  management  system  and  appreciate  the  technology  required  to  use  this  both  locally  and 
remotely. 

9.4.2  The  staff  in  the  Richmond  EOC  did  observe  that,  both  on  the  days  of  the  dry  run  and  the  main  experiment,  there 
was  too  much  focus  on  the  filming  goals  and  not  much  allowance  made  for  users  to  examine  the  actual  technology. 
Hands-on  use  of  the  EmerGeo  tool  was  limited,  with  much  of  the  filming  devoted  to  blue  screens.  As  a  result  it  was 
felt  that  more  could  have  gained  with  respect  to  understanding  of  the  tool.  Subsequent  meetings  will  be  arranged 
however  with  EmerGeo  to  follow-up  on  this  matter. 

9.4.3  It  was  determined  that,  in  the  event  of  a  real  earthquake,  it  would  be  useful  to  have  the  visual  representation  from 
the  Smart  Client,  showing  the  shaking  intensity  and  the  areas  most  affected  by  the  earthquake,  thereby  confirming 
whether  or  not  the  ground  motion  effects  of  such  a  large  event  in  the  Cascadian  subduction  zone  would  affect 
Richmond  significantly.  The  extent  of  damage  in  a  given  area  would  be  determined  fairly  quickly  from  field  reports  f 
Having  the  shake  map  generated  as  a  live  picture  would  allow  those  reports  to  be  corroborated  by  area  within 
Richmond  and  would  also  ascertain  whether  the  model  is  accurate  and  could  be  relied  on  for  assessment  purposes. 

9.4.4  It  was  felt  that  this  information  would  also  useful  for  planning  responses  to  specific  earthquake  scenarios, 

9.4.5  The  outputs  from  Hazus-MH,  if  developed  to  the  point  where  they  could  be  deemed  reliable,  would  provide 
additional  more  specific  impact-related  outputs  which  could  be  used  to  augment  the  scenario  and  broaden  the 
problem  appreciation  for  planning  purposes. 

9.4.6  From  a  technical  stand  point,  integration  between  a  municipal  instance  of  an  EmerGeo  and  BCeMap  was 
explored  and  it  was  found  that  it  was  relatively  straight  forward  to  implement  a  basic  Web  Mapping  Service  interface 
between  the  two  systems.  The  WMS  source  can  be  created  in  EmerGeo  in  administration  mode  in  a  couple  of  steps, 
i.e.  selecting  the  data  to  be  exported  and  the  type  of  interface  (in  this  case  WMS,  the  other  options  being  KML  and 
GeoRSS).  This  then  creates  an  external  url  which  can  be  copied  and  used  by  the  consuming  system.  The  WMS  was 
consumed  in  BCeMap  by  a  service  on  ArcGIS  server  and  then  republished  as  part  of  the  map  services  to  the 
BCeMap  browser  client. 

9.4.7  There  were  a  number  of  teething  issues  and  more  fundamental  issues  however  with  the  mechanism: 

•  The  services  needed  to  be  published  on  a  port  that  could  be  consumed  at  GeoBC  (most  ports  in  BC 
government  networks  are  blocked  above  1500  and  the  default  for  EmerGeo  was  8888).  An  open  port  that  did 
work  was  8080. 

•  The  default  projections  used  by  EmerGeo  was  a  Web  Mercator  projection  i.e.  EPSG:3785  (as  originally  used 
by  Google)  or  900913  (the  open-source  OpenLayers  projection).  Neither  was  supported  in  BCeMap  as  these 
have  now  been  deprecated8.  The  EmerGeo  service  was  re-configured  to  EPSG:3857  (that  also  replaced  the 
ESRI:102100)  and  this  could  then  be  consumed  by  BceMap. 

•  A  more  fundamental  issue  however  was  that  the  EmerGeo  publishing  mechanism  creates  a  new  layer  in  the 
WMS  service  for  every  incident.  This  is  illustrated  in  Figure  40. 


8  by  the  Eurpoean  Petroleum  Survey  Group  (EPSG)  who  publish  a  dataset  of  parameters  for  co-ordinate  reference 
system  and  co-ordinate  transformation  description 
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Figure  40  -  WMS  layer  tree 


9.4.8  This  is  a  design  decision  that  then  allows  the  user  to  toggle  this  layer  on  and  off  independently  in  the  consuming 
system.  However  the  ArcGIS  services  in  BCeMap  assumes  that  the  structure  of  the  WMS  is  not  changing  and  caches 
the  structure,  and  therefore  it  does  not  recognize  subsequent  incidents.  It  was  not  scoped  and  addressed  as  part  of 
the  project  to  develop  the  ability  to  render  new  incidents  in  a  standard  (i.e.  non-changing)  set  of  layers  to  work  with 
BCeMap.  However  this  could  be  done  if  WMS  was  the  preferred  method  of  integration  with  BCeMap  going  forward. 

9.4.9  In  the  time  available  it  was  also  not  possible  to  configure  or  evaluate  the  WMS  “identify”  services  i.e.  the 
GetFeaturelnfo  request  service  which  allows  a  user  to  click  on  an  incident  on  screen  and  retrieve  further  data  .  This  is 
only  supported  by  some  WMS  services  and  XML  or  text  is  returned.  It  is  unknown  how  this  would  need  to  be 
configured  to  support  a  usable  display  in  BCeMap,  however  the  viewing  pane  in  BCeMap  is  unstructured  therefore  the 
implication  is  that  configuration  would  have  to  be  done  at  source.  In  addition  the  feature  information  fields  could  not  be 
used  for  filtering  the  display  in  the  same  way  that  has  been  configured  for  MASAS  (i.e.  if  the  user  is  looking  for 
incidents  of  a  certain  type  or  age  etc.)  Only  the  fixed  layer  groupings  could  be  used  for  this  purpose. 

9.4.10  It  should  be  noted  also  that  WMS  does  not  specify  an  incorporated  security  configuration,  and  an  additional 
security  layer  would  have  to  be  applied  e.g.  at  the  network  layer  in  the  form  of  a  point  to  point  vpn  or  ssl  connection. 

9.4.11  The  experiment  showed  that  sharing  information  out  of  a  local  incident  management  system  to  BceMap  can  be 
operationally  useful,  especially  for  provincial  emergency  management  resources  to  quickly  visualise  what  is 
happening  o  the  ground  (referenced  by  situation  reports  for  example).  However  WMS  would  not  be  the  best  option  for 
this.  BCeMap  would  need  to  be  configured  for  every  source,  and  the  programming  and  configuration  of  each  source 
to  be  compliant  may  not  be  trivial.  It  would  be  far  better  if  each  system  was  able  to  publish  to  MASAS  i.e.  in  a  single 
standard  format  and  there  would  be  no  additional  or  on-going  work  required  in  BCeMap  to  consume  each  additional 
source  as  they  came  on  board. 

9.4.12  It  would  also  be  possible  to  host  a  BCeMap  window  within  EmerGeo  (as  a  pane  can  be  configured  to  point  to  the 
BCeMap  url)  and  this  would  have  been  possible  if  the  ssl  certificate  on  the  GeoBC  delivery  site  was  up-to-date, 
however  this  was  expired  and  the  security  mechanism  within  the  Internet  Explorer  Browser  (used  during  the 
experiment)  prevented  the  map  from  being  displayed.  The  issue  could  have  been  fixed  or  worked  around,  however  it 
was  determined  that  there  is  no  real  operational  benefit  in  having  BCeMap  hosted  within  a  window  in  EmerGeo  apart 
from  perhaps  having  all  applications  grouped  together  in  one  container  for  ease  of  user  access.  This  does  have  some 
merit  especially  for  new  users  and  or  users  whose  training  may  not  have  been  very  recent  when  the  EOC  activates, 
however  the  user  still  has  to  log-on  separately  to  BCeMap  and  has  to  toggle  between  panes  to  see  data  hosted  in  this 
system  vs  that  unique  to  EmerGeo. 


9.5  Vignette  2:  Recommendations 

9.5.1  It  is  recommended  that  a  hosted  EmerGeo  Fusionpoint  or  a  similar  system  is  considered  as  a  solution  for 
Richmond  Emergency  Management  for  both  their  incident  management  and  awareness  component  of  their  Virtual 
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EOC  concept.  This  solution  should  be  considered  alongside  other  similar  solutions  against  the  criteria  of  cost,  benefit 
and  features,  and  the  features  should  include  the  ability  to  consume  and  publish  to  MASAS  and  support  remote  users. 

9.5.2  Based  on  the  findings  above  it  is  also  recommended  that  for  low  cost  set-up  and  maintenance  and  management 
of  awareness  information  between  systems,  that  MASAS  would  be  the  better  mechanism  for  integration  with  other 
systems  rather  than  WMS.  In  summary  the  main  reason  for  this  are  that  the  source  systems  would  publish  data  in  a 
consistent  and  standard  format,  with  fields  mapped  to  filter  and  display  tools  in  the  destination  systems  (e.g. 
BcEMap),  and  there  would  be  no  additional  work  at  the  receiving  systems  to  be  able  to  consume  from  additional 
publishing  sources.  The  MASAS  feed  also  has  basic  security  built  in  to  the  standard  connection  at  the  application 
layer. 

9.5.3  In  the  absence  of  an  integrated  incident  management  and  awareness  system  (like  Fusionpoint),  BCeMap  could 
be  rolled  out  to  Municipalities  subject  to  appropriate  support  and  training,  however  a  tool  like  Fusionpoint  could  take 
over  the  role  of  situational  awareness  if  all  the  same  sources  are  available  as  are  available  for  BCeMap  (particularly  if 
the  main  sources  continue  to  move  towards  being  delivered  through  MASAS). 

9.5.4  It  was  felt  by  the  emergency  management  staff  at  Richmond,  that  the  groundshake  outputs  from  the  EmerGeo 
Smart  Client  and  the  Hazus-MH  outputs  were  both  very  useful  and  would  have  application  in  the  event  but  also  in  the 
planning  for  such  an  event.  Both  products  may  be  considered  for  implementation  subject  to  cost  and  resource 
implications. 

9.5.5  Although  not  explored  in  detail  in  the  experiment,  the  usefulness  of  the  AMECom  truck  was  apparent,  and  the 
potential  for  use  in  any  number  of  roles  or  situations  to  recover  power  and/or  communications  facilities  for  critical 
infrastructure.  It  is  recommended  that  various  critical  infrastructure  operators  (for  example  Vancouver  International 
Airport)  could  be  approached  to  develop  operational  procedures  to  implement  the  truck  in  a  recovery  mode  after  loss 
of  critical  services. 
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10.  Vignette  3:  Viaduct  Collapse  and  Crowd-sourcing  Incident  Information 

10.1  Vignette  3:  Introduction 

10.1.1  This  vignette  is  designed  around  events  after  the  main  earthquake  event,  centred  on  action  at  the  Vancouver 
Emergency  Operations  Centre  (EOC)  in  response  to  incidents  around  the  city  especially  the  collapse  of  part  of  the 
Georgia  Viaduct  as  a  result  of  aftershocks.  The  teams  involved  at  the  Vancouver  EOC  include  the  311  contact  centre 
team  as  well  as  EOC  staff.  SFU  students  were  also  involved  in  creating  and  processing  incidents. 

10.1 .2  In  normal  operations  the  31 1  contact  centre  takes  calls  from  citizens  requesting  service,  information  or  registering 
a  civic  concern.  The  concept  is  that  during  a  crisis  the  normal  flow  of  citizen  requests  will  be  interrupted  and  the  31 1 
centre  will  be  able  to  take  on  the  additional  role  of  assessing  reports  from  the  public  regarding  damage  or  need  for 
assistance,  both  from  telephone  calls  as  well  as  social  media  websites.  Such  candidate  data  sources  include  Twitter 
and  Facebook.  For  the  experiment,  Ushahidi  was  chosen  since  it  is  a  geospatial  reporting  technology  that  has  been 
developed  by  an  open  source  project  and  sites  have  been  set  up  and  used  in  the  recent  major  Christchurch  and 
Honshu  earthquakes.  Ushahidi  has  also  been  the  subject  of  research  by  the  SFU  Faculty  of  Communication,  Art  and 
Technology,  and  a  site  set  up  for  one  of  their  projects  was  used  for  this  experiment. 

10.1.3  The  objectives  of  the  vignette  were  to  experiment  with  the  processes  that  are  required  for  the  311  team  to 
process  the  information  from  such  sources  and  submit  that  information  into  the  existing  formal  emergency 
management  systems.  In  this  case  the  formal  system  was  chosen  to  be  E  Team  and  there  is  also  an  interface  from  E 
Team  to  BCeMap,  as  a  means  by  which  the  information  could  also  be  shared  with  the  South  West  PREOC.  This 
supports  a  discussion  around  a  request  for  bringing  in  heavy  machinery  to  deal  with  rubble  disposal. 

10.1.4  As  a  side-event  in  this  vignette  a  picture  was  taken  on  an  Android  phone  of  the  EOC  board  room  during  the 
experiment  briefing.  The  picture  was  tagged  and  uploaded  to  SAMapper,  one  of  the  US  technologies  involved  in  the 
experiment,  and  this  tagged  report  and  image  was  sent  from  SAMapper  through  MASAS  to  BCeMap  to  demonstrate 
the  technologies  and  interfaces  (not  an  integral  part  of  the  overall  scenario). 

10.2  Vignette  3:  The  Technologies 

10.2.1  The  main  technologies  involved  in  this  vignette  are  illustrated  in  Figure  41  Error!  Reference  source  not  found.. 
The  process  starts  with  the  ability  for  the  public,  played  by  SFU  students  in  the  experiment  to  capture  events  on  the 
streets  as  reports  in  Ushahidi,  using  cell  phones  or  laptops  e.g.  in  a  coffee  shop.  Volunteer  adjudicators  are  then  able 
to  vet  the  reports  submitted  and  if  approved,  they  are  then  displayed  on  the  public  facing  Ushahidi  web  site  that  was 
set  up  by  for  the  experiment. 
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Students  (acting  as 
Public)  -  creating 
reports 


311  call  centre  team 
-  filtering  info  and 
putting  into  Eteam 
"Call  centre  reports" 


Canned  reports 


City  of  Vancouver 
staff  selecting  items 
from  "call  centre 
reports"  for  turning 
into  "Incidents" 
where  the  city  has  to 
respond. 


SW  PREOC  able  to 
see  reports  from  CoV 
Eteam  pulled  up  on 
screen 


Figure  41  -  Vancouver  EOC  Crowd  Sourcing  Flow 


10.2.2  The  311  contact  centre  team  would  then  review  all  the  events  and,  if  a  report  seems  real  and/or  has  sufficient 
corroboration  then  they  would  translate  the  message  into  a  “Call  Centre  Report”  in  E  Team,  in  the  same  way  that  a 
telephone  call  from  the  public  might  be  captured  from  the  public  into  E  Team. 

10.2.3  The  City  of  Vancouver  EOC  team  would  then  see  the  call  centre  reports  and  determine  whether  it  is  an  incident 
that  the  city  has  to  respond  to.  If  so  then  the  reports  would  be  turned  into  “incident  reports”  in  E  Team  and  tracked  as 
for  any  other  incident  captured  in  that  system.  The  interface  to  BCeMap  allows  the  incident  to  be  published  to 
BCeMap  and  for  the  incident  details  to  be  visible  if  the  user  selects  the  E  Team  layer  in  the  user  interface. 


10.3  Vignette  3:  The  Action 

10.3.1  The  action  centres  on  members  of  the  public  observing  a  section  of  the  Georgia  Viaduct  collapsing  in  the  vicinity 
of  where  the  viaduct  crosses  Quebec  Street,  near  BC  stadium  place. 

10.3.2  A  report  was  entered  into  Ushahidi  by  students  acting  as  the  public  and  is  validated  and  presented  in  the  Ushahidi 
Vancouver  Earthquake  web  site.  Figure  42Figure  43Error!  Reference  source  not  found,  illustrates  the  report 
capture  screen  in  Ushahidi  and  Figure  43  illustrates  how  this  would  was  presented  in  the  public  web  site  display  once 
the  report  was  validated  by  the  Ushahidi  volunteers.  This  step  is  to  filter  out  reports  that  are  clearly  spurious  or  reveal 
personal  information  and  would  be  supported  by  the  Ushahidi  site  volunteers. 
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■jfc  Favorites  <g[  Vancouver  Earthquake 
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SUBMIT  A  REPORT 
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Submit  a  New  Report 

Report  Title 


People  trapped  in  car  -  Georgia  Viaduct  Collapse 


Description 


Folks  trapped  in  car  due  to  rubble  from 
collapsing  Viaduct 


Date  &  Time:  Today  at  9:06  am  (America/Vancouver) 
Categories 

1 .0  Incidents  &  Damage  ,  3.0  Utilities  Outage 

®  1.1  Trapped  People 
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Figure  42  -  Report  capture  process 
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Figure  43  -  Reports  of  people  trapped  in  cars  near  the  Georgia  Viaduct 
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2.  By  filling  this  form 
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10.3.3  The  311  call  centre  team  then  reviewed  all  the  messages  in  Ushahidi  (see  Figure  44)Error!  Reference  source 
not  found,  for  another  example  report)  which  can  also  be  reviewed  in  list  form  (see  Figure  45). 


FILTERS  ■+  I  NEWS  PICTURES  VIDEO  ALL 


4  CATEGORY  FILTER  [HIDE] 


□  ALL  CATEGORIES 


■  1.0  INCIDENTS  &  DAMAGE 

■  2.0  EMERGENCY 
RESOURCES 

■  3.0  UTILITIES  OUTAGE 


How  to  Report 

1.  By  sending  an  email  to 
rr_ushahidi@sfu.ca 

2.  By  filling  this  form 


Jun2011  |T|tD  |  Jun  2011  M 

Figure  44  -  Other  Ushahidi  Reports 


►  Play 


Figure  45  -  List  view  of  reports 
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10.3.4  Once  the  viaduct  collapse  report  has  been  determined  to  be  of  interest  to  the  city  (especially  as  it  involves  both  an 
incident  involving  people  requiring  assistance  but  also  failure  of  a  major  piece  of  city  infrastructure,  then  the  call 
centre  report  in  E  Team  is  captured  (see  Figure  46). 


Figure  46  -  Call  Centre  Report  in  E  Team 


10.3.5  When  reviewed  by  staff  in  the  Vancovuer  EOC  the  call  centre  report  was  be  converted  to  an  incident  report  for 
further  action  and  management.  See  Figure  47  for  the  report  and  Figure  48  for  the  list. 
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Figure  47  -  E  Team  incident  report 


10.3.6  In  the  experiment,  subsequent  to  the  report  being  published  and  other  reports  being  received  the  City  EOC 
determined  that  there  were  issues  gaining  access  for  cranes  clearing  rubble  in  the  vicinity  of  the  viaduct  and  a  call 
was  executed  between  the  City  EOC  and  the  South  West  PREOC  to  discuss  the  location  of  the  viaduct  collapse,  the 
difficulties  getting  cranes  into  the  area  due  to  other  road  closures  and  an  alternate  means  of  bringing  cranes  in  by 
barge  was  discussed.  The  visual  representation  of  the  collapse  in  BCeMap  can  be  seen  in  Figure  49. 
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Figure  49  -  Representation  of  Georgie  Viaduct  collapce  in  BCeMap 


10.4  Vignette  3:  Experimental  Findings 

10.4.1  The  311  contact  centre  is  a  relatively  recent  addition  to  the  City’s  capabilities  and  the  team  was  very  interested  in 
developing  operational  procedures  with  the  Vancouver  EOC  to  assist  with  major  incidents  and  explore  ways  in  which 
the  resource  could  be  put  to  best  use  in  these  circumstances. 

10.4.2  The  use  of  social  media  as  a  means  to  interact  with  the  public  is  a  major  topic  in  the  emergency  management 
community  due  to  the  efficiencies  in  the  gathering  of  information  that  may  otherwise  not  be  available,  especially  when 
resources  are  heavily  engaged  with  other  tasks. 

10.4.3  The  experiment  only  covered  the  one  way  flow  of  information  from  the  public  to  the  emergency  management 
organizations,  but  the  flow  could  also  take  place  the  other  way.  For  example  the  set-up  and  availability  of  reception 
centres  could  be  communicated  out  to  the  public  through  a  site  such  as  Ushahidi  (as  illustrated  in  Figure  44  above). 

10.4.4  As  part  of  the  experiment  it  was  discovered  that  there  was  a  flaw  in  the  E  Team  system  that  prevented  call  centre 
reports  from  being  converted  automatically  to  incident  reports,  and  this  has  been  reported  up  to  the  E  Team/NC4  help 
desk. 

10.5  Vignette  3:  Recommendations 

10.5.1  It  is  recommended  that  the  following  areas  could  be  explored  in  future  experiments  with  such  technologies. 

10.5.2  Flaving  proved  the  interest  and  practicality  of  having  31 1  staff  execute  the  role  of  vetting  Ushahidi  reports,  it  would 
be  beneficial  in  terms  of  time  saving  to  be  able  to  automatically  extract  the  corroborated  reports  from  Ushahidi  into  E 
Team.  It  is  understood  that  at  a  system  level  it  should  be  possible  to  interface  with  Ushahidi,  or  such  an  interface 
could  be  built  by  the  open  source  community.  This  interface  should  be  able  to  pull  specific  reports  and  push  into  E 
Team  using  a  web  service  on  E  Team  available  for  that  purpose.  Ideally  there  would  be  a  control  in  the  Ushahidi 
screen  that  could  be  invoked  on  a  selected  report  and  any  additional  information  added  (e.g.  details  on  the  user 
pushing  the  data,  and  any  corroborating  information  from  other  reports  that  may  be  added)  and  then  the  Call  centre 
report  would  be  generated  automatically. 

10.5.3  Another  option  is  that  a  similar  adapter  could  be  invoked  (instead  of,  or  in  parallel)  that  could  create  a  MASAS 
message  and  pushed  to  a  MASAS  hub  for  wider  consumption,  however  this  would  more  likely  be  a  step  further  into 
the  process  (i.e.  when  the  call  centre  report  is  converted  to  an  incident  in  E  Team). 

10.5.4  Similar  interfaces  with  Facebook  and  Twitter  should  also  be  considered  using  a  similar  process.  This  would  then 
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cover  the  main  sources  of  public  generated  information. 

10.5.5  Operational  procedures  around  publishing  city  Emergency  Social  Services  resources  (e.g.  reception  centres,  etc.) 
and  people  finding  processes9  could  also  be  explored  as  a  means  of  communicating  efficiently  with  the  public. 

10.5.6  It  is  also  recommended  that  the  possibility  of  adopting  the  process  above  as  a  true  operational  procedure  is 
evaluated.  As  part  of  that  evaluation,  the  means  of  marketing  to  the  public  the  existence,  purpose  and  usage 
guidelines  for  specific  Ushahidi,  Facebook  and  Twitter  web  sites  should  be  defined,  together  with  identifying  the 
funding  and/or  messaging  to  the  media  required  for  such  an  eventuality. 


9  It  was  observed  that  the  public  trying  to  find  relatives  was  a  significant  use  of  the  Honshu  Ushahidi  web  site  following  the 
major  earthquake  in  Japan. 
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11.  Vignette  4:  SW  PREOC  Regional  Roll-Up 


11.1  Vignette  4:  Introduction 

11.1.1  This  vignette  consists  of  the  overall  view  of  the  main  event  and  subsequent  events  from  the  perspective  of  the 
South  West  PREOC  during  a  regional  roll-up  and  discussion  between  the  Director,  Operations  and  Logistics 
positions.  The  vignette  showcases  BCeMap  and  the  ability  to  provide  situational  awareness  across  the  province,  and 
also  the  CAP/ATOM  Message  Generator,  a  tool  that  was  built  specifically  for  the  project  and  has  been  turned  over  as 
open  source  code  to  the  MASAS  development  community.  The  scenario  generator  produces  messages  that  simulate 
inputs  from  various  other  existing  and  candidate  sources  that  could  be  developed,  if  there  was  funding  and  the 
aspiration  to  implement  from  an  operational  perspective. 

11.2  Vignette  4:  The  Technologies 

11.2.1  BCeMap  is  described  in  Section  6.2,  and  the  scenario  generator  is  described  in  Section  6.8  and  the  MASAS  hub 
is  described  in  Section  6.10. 

11.2.2  The  scenario  generator  had  several  message  sequences  loaded  in  to  support  the  various  vignettes  in  this  project 
and  provide  context  for  the  participants.  Several  of  these  scenarios  were  run  back  to  back  to  provide  the  context  for 
the  users  through  BCeMap  for  this  particular  vignette. 

11.2.3  There  were  two  alternative  viewing  technologies  that  were  set  up  to  consume  messages  from  the  MASAS  hub 
and  allow  Federal  and  other  observers  of  the  experiment  to  follow  along  after  the  initial  briefing  session  given  at  the 
start  of  the  day.  These  were: 

•  the  MASAS  viewer  (at  http://cause.masas.ca/viewer  and  also  see  Section  6.10.3)  which  had  a  default 
password  set  up  to  allowed  any  user  using  this  url  to  connect  and  observe  the  action.  See  the  screenshot  in 
Figure  50. 
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Figure  50  -  MASAS  online  viewing  tool 
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In  addition  an  ArcGIS  web  site  enabled  with  the  open  source  MASAS  ESRI  Flex  Tools  was  configured  to 
point  to  the  CAUSE  MASAS  hub.  This  was  established  by  the  MASAS  National  infrastructure  Team  (see 
Section  6.11  and  the  screenshot  in  Figure  51). 
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Figure  51  -  MEFT  Tool  View  of  CAUSE  experiment. 


1 1 .2.4  Several  sources  were  simulated  for  this  vignette  as  shown  in  Figure  52,  including: 

•  Strong  Motion  and  Bridge  Seismic  sensors  that  are  part  of  the  Smart  Infrastructure  and  Monitoring  System 
(SIMS)  that  is  being  developed  by  UBC  on  behalf  of  the  Ministry  of  Transportation. 

•  The  Drive  BC  feed  for  road  closures 

•  The  NRCan  feed  for  earthquakes 

•  A  potential  Tsunami  Alert  messaging  application  that  would  be  managed  by  the  PECC 
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Figure  52  -  MASAS  Hub  and  Event  Viewing  Options 


11.2.5  For  the  purposes  of  describing  the  action  in  this  vignette  the  output  as  presented  in  BCeMap  is  used  for  the  rest 
of  the  descriptions. 

11.2.6  Core  to  this  vignette  and  most  of  the  other  vignettes  is  the  use  of  BCeMap  as  a  key  presentational  tool  for  the 
Province  of  British  Columbia.  An  important  part  of  the  leave-behind  for  this  experiment  is  the  development  of  the 
interface  from  MASAS  to  BCeMap.  This  is  covered  in  detail  in  Appendix  A  and  this  vignette  was  one  of  the  main 
testing  grounds  for  many  of  the  events  and  alerts  that  might  be  pushed  to  BCeMap. 

11.3  Vignette  4:  The  Action 

11.3.1  The  CAP/Atom  message  generator  was  used  to  simulate  the  main  earth  quake  event  and  an  USGS  tsunami 
warning  and  these  were  the  first  events  published  to  the  MASAS  hub.  In  a  real  situation  the  earthquake  information 
would  come  from  NRCan  Earthquakes  Canada  who  now  have  a  live  feed  of  earthquake  events  available,  and  this 
could  also  be  augmented  with  a  feed  from  the  USGS  (who  are  also  able  to  issue  earthquake  events  automatically, 
with  accompanying  Tsunami  alerts).  The  simulated  messages  are  illustrated  in  Figure  53. 
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Figure  53  -  Cascadian  Subduction  Zone  Earthquake 


11.3.2  In  addition  to  the  main  event,  the  experiment  simulated  the  possibility  of  MASAS  being  fed  information  from  a 
number  of  other  sources  that  would  be  useful  in  the  immediate  aftermath  of  an  earthquake.  The  first  such  source  was 
an  array  of  strong  motion  sensors  that  are  designed  to  detect  acceleration  and  displacement  and  are  located  in 
various  places  around  the  lower  mainland  (many  schools  and  universities)  and  are  networked  into  the  Smart 
Infrastructure  Monitoring  Systems  (SIMS). 

11.3.3  The  output  of  these  sensors  could  be  used  to  create  MASAS  alerts  for  spectral  intensity  above  a  certain 
threshold.  UBC  and  the  Ministry  of  Transportation  were  approached  and  have  expressed  interest  regarding  the 
possibility  of  implementing  this  interface;  however,  the  recent  global  seismic  events  and  other  pressures  on  the  SIMS 
project  prevented  this  initiative  from  being  progressed  for  the  purposes  of  the  experiment. 


Figure  54  -  Strong  Motion  Sensors 


11.3.4  The  output  from  bridge  sensors  was  also  simulated  in  this  Vignette.  All  modern  bridges  in  the  lower  Mainland  are 
being  fitted  with  seismic  sensors  and  stress  gauges  and  monitoring  systems  that  can  indicate  whether  a  bridge  or 
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bridge  component  has  been  damaged,  or  may  have  been  subject  to  shaking  that  exceeds  the  bridge’s  design 
parameters  through  extrapolation  based  on  measurements  from  nearby  sensors.  The  monitoring  system  could  then 
output  messages  useful  to  Emergency  Management  organizations  for  each  affected  bridge  that  indicates  whether 
action  needs  to  be  taken  e.g.  that  the  bridge  needs  to  be  inspected  and/or  closed. 

1 1 .3.5  The  output  of  2  potential  bridge  sensor  alerts  is  illustrated  in  Figure  55. 


Figure  55  -  Bridge  Sensor  Alerts 


11.3.6  The  experiment  also  simulated  the  process  by  which  the  Provincial  Emergency  Coordination  Centre 
(PECC)  might  issue  the  BC  specific  alerts  based  on  the  Tsunami  alerts  received  from  the  West  Coast  and  Alaska 
Tsunami  Warning  Centre  (WCATWC). 


Figure  56  -  Tsunami  Alerts 

11.3.7  Figure  56  shows  how  tsunami  warnings  might  be  represented  in  BCeMap  using  Polygons  for  each  of  the 
designated  warning  areas  (Areas  A  through  E)  together  with  additional  information  regarding  onset  and  wave  heights. 

11.3.8  To  support  the  issuing  of  these  messages  from  the  PECC  it  would  be  possible  to  implement  a  desktop  based 
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application  that  would  be  similar  to  the  CAP/Atom  message  builder,  but  with  a  simpler  interface  and  pre-configured 
polygons  for  the  warning  areas.  This  would  be  capable  of  publishing  the  warnings  to  MASAS  and  thence  to  other 
consuming  systems.  This  step  would  need  to  be  inserted  into  the  operational  procedures  in  EMBC/PECC,  most  likely 
to  take  place  after  the  Provincial  Emergency  Notification  System  (PENS)  is  activated  to  issue  the  time  critical 
notifications.  This  would  still  be  of  value  to  the  Emergency  Management  community  as  Tsunami  effects  can  last  more 
than  12  hours  after  the  main  event. 

11.3.9  It  should  also  be  possible  to  track  the  status  of  municipal  EOC  activations,  declarations  of  emergency,  and 
evacuations,  through  alerts  communicated  from  municipalities  possibly  via  MASAS.  It  is  not  discussed  here  what 
system(s)  would  generate  these  messages  (i.e.  whether  this  is  possible  from  municipal  systems  themselves,  or 
captured  and  disseminated  at  a  provincial  level  (from  E  Team  or  other  systems),  however  the  simulator  allowed  an 
EOC  activation  to  be  represented  in  BCeMap,  to  show  what  this  might  look  like  if  such  notifications  were  available. 
See  Figure  57. 


Figure  57  -  Vancouver  EOC  Activation  event 


11.3.10  BCeMap  already  has  interfaces  to  Drive  BC  and  is  therefore  able  to  present  highway  status  information  from  a 
live  feed.  In  the  experiment  several  rock  falls  were  simulated,  one  in  the  Fraser  valley  near  Flope,  effectively  blocking 
off  transportation  to  and  from  Vancouver  to  the  East  and  two  rock  falls  on  the  sea  to  sky  highway  which  isolates 
Vancouver  to  the  north.  This  circumstance  results  the  SW  PREOC  having  to  consider  moving  resources  from  the 
interior  through  the  United  States.  This  has  been  a  real  scenario  in  the  past  during  the  avian  flu  epidemic. 
Transportation  would  move  south  via  Osoyoos  and  across  one  of  the  roads  or  highways  south  of  the  parks  in 
Washington  and  then  North  up  through  the  15  corridor.  The  rock  falls/road  closures  are  illustrated  in  BCeMap  in  Figure 
58.  The  scenario  and  investigation  of  the  highways  in  the  USA  by  the  SW  PREOC  is  discussed  further  in  the  next 
vignette. 
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Figure  58  -  Rock  Falls 


11.3.11  Also  during  the  experiment,  an  instance  of  the  CAP/Atom  Message  Generator  was  run  remotely  (from  Ottawa)  to 
simulate  the  output  of  the  Langley  Emergency  Operations  Centre.  This  message  pack  was  run  in  and  consumed  by 
BCeMap  for  presentation  and  the  state  of  the  highway  and  Langley  hospital  was  used  in  the  vignette  dialogue  at  the 
PREOC. 

11.4  Vignette  4:  Experimental  Findings 

11.4.1  Technology  findings:  The  experiment  was  a  catalyst  for  finalizing  a  feed  from  Earthquakes  Canada  to  MASAS. 
A  number  of  challenges  were  overcome  to  deliver  the  feed  including  conversion  of  the  feed  from  NRCan  to  be 
consistent  with  the  CAPAN  CAP  Event  Location  Layer.  One  issue  was  encountered  relating  to  the  repeating 
information  block  in  the  CAP-CP  message  to  carry  the  French  version  of  the  Earthquake  alerts.  The  repeat  elements 
caused  a  script  to  fail  in  BCeMap  and  it  was  not  possible  to  fix  and  promote  the  code  through  the  environments  in 
time  for  the  experiment,  so  for  the  actual  experiment  fall  back  to  the  simulation  was  used. 

11.4.2  There  were  a  number  of  environment  and  delivery  issues  with  BceMap.  These  are  documented  in  Appendix  A, 
but  were  overcome  in  time  for  the  experiment. 

11.4.3  One  other  issue  with  BCeMap  as  currently  implemented  is  that  the  update  period  is  set  to  one  hour.  If  live  feeds 
from  sensors,  and  a  Tsunami  warning  generation  application  is  implemented,  then  that  refresh  rate  will  be  insufficient 
for  the  type  of  information  being  displayed  (i.e.  that  needs  to  be  much  more-real  time). 

11.4.4  The  use  of  the  CAP/Atom  Message  Builder  tool  was  extensive  during  this  part  of  the  experiment,  and  went 
through  a  number  of  iterations  as  the  tool  was  tested  and  the  user  interface  was  refined.  Features  that  were  added 
that  made  the  tool  more  useable  than  the  early  versions  included: 

•  The  ability  to  bulk  reset  all  the  messages  in  the  scenario  (ready  to  run  the  scenario  again) 

•  The  ability  to  bulk  update  the  expiry  dates  and  times  on  all  messages  in  the  scenario.  This  was  used  to  set 
the  messages  up  to  drop  off  automatically  after  each  test  run  so  that  the  hub  did  not  need  to  be  flushed  or  for 
the  the  messages  expired  manually  by  hand. 

•  The  ability  to  change  and  save  scenario  names  (as  their  purpose  evolves). 

11.4.5  Other  features  of  fixes  that  have  been  added  to  the  open  source  contribution  since  the  experiment  that  are 
making  the  tool  more-user  friendly  include:10 


10  Source:  Darrell  O’Donnell 
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•  Times  -  there  were  problems  with  saving  and  restoring  messages  -  timezone  offsets  lost  the  UTC  delta  on 
save  and  on  restore,  and  crossing  midnight  was  faulty. 

•  Entry  support  -  enhanced  support  for  MASAS  Entries  (i.e.  messages  that  don’t  have  accompanying  CAP-CP 
message  constructs  as  they  are  informational  rather  than  alerting  in  nature) 

•  Map  Integration  -a  basic  map  control  has  been  added  in  that  makes  defining  points  and  polygons  easier. 

1 1 .4.6  Process  findings:  A  number  of  the  types  of  alerts  or  pieces  of  information  that  we  were  presenting  in  BCeMap 
did  not  appear  to  contain  an  event  type  in  the  event  list,  most  notably  the  output  of  any  sensors  e.g.  strong  motion 
ground  shake  sensors,  or  seismic  bridge  sensors,  and  also  the  status  of  each  municipalities’  EOCs,  declarations  of 
emergency  or  evacuations.  It  is  understood  that  these  may  not  be  handled  as  alerts  and  more  as  ‘entries’  however 
there  needs  to  be  a  standard  symbol  set  that  can  represent  these  items. 

11.4.7  Through  the  course  of  experiment  development  it  became  apparent  that  a  major  earthquake  results  in  a  very 
large  number  of  actual  earthquake  events  (large  and  small  aftershocks,  scattered  around  the  seismically  active  areas) 
and  therefore  the  readings  from  the  seismic  sensors  would  be  output  in  a  continuous  succession  and  therefore  be 
somewhat  difficult  to  interpret  for  users  that  are  not  familiar  with  the  reading  outputs.  The  representation  used  in  the 
experiment  was  relatively  simplistic  and  did  not  deal  with  the  realities  of  making  such  outputs  more  useful 

11.4.8  More  sophisticated  scenarios  could  be  run  if  the  CAP/Atom  Message  Generator  tool  had  an  update  capability, 
however  the  create  message  function  in  the  tool  was  certainly  sufficient  to  create  enough  messages  for  a  basic 
scenario  and  realistic  backdrop  to  the  experiment. 

1 1 .4.9  For  an  event  as  large  as  the  Cascadian  Subduction  zone,  it  must  be  understood  that  there  would  be  a  very  large 
quantity  of  information  being  generated  and  the  more  that  can  be  captured  and  presented  automatically  without 
human  intervention  the  better,  potentially  with  links  through  to  other  websites  containing  more  details  and 
explanations  of  events  and  the  data  presented.  During  the  execution  of  the  experiment  the  use  of  BCeMap  to  gain  an 
overview  or  areas  affected,  EOCs  activated,  roads  closed,  Tsunami  effects  and  aftershocks,  locations  and  magnitude 
proved  effective  for  the  operational  staff  and  allowed  immediate  visualization  of  the  situation. 

11.5  Vignette  4:  Recommendations 

11.5.1  It  was  recommended  that  a  more  formal  release  planning  process  would  be  put  in  place  to  avoid  a  repeat  of  the 
deployment  issues  encountered  prior  to  the  experiment.  A  workshop  to  define  this  was  held  between  GeoBC,  Citizens 
Services,  Client  Services  Natural  Resource  and  facilitated  by  Planetworks  and  actions  agreed,  including  revisions  to 
the  documentation,  planning  steps  added  to  the  delivery  process  as  defined  in  the  table  below. 


Agreed  project 
delivery  process 

Steps 

who 

Description 

Change  definition 
meeting 

Called  by  and  arranged  by 

PM  (ESRI/Planetworks) 

Identify  services  to  be  changed, 
ensure  any  changes  to  delivery 
process  is  understood 

Pre  delivery  meeting 

Called  by  and  arranged  by 

PM  (ESRI/Planetworks) 

Confirms  checklist  of  items  to  be 
working  prior  to  delivery,  e.g. 
accounts,  services  etc.  clarify  roles  and 
responsibilities  and  timelines. 

Notification  of 
environment  ready 

Citizens  Services 

Delivery 

ESRI/Planetworks 

FME  scripts  can  be  pre  tested,  and 
then  packaged  as  part  of  main  ESRI 
delivery. 

1 1 .5.2  As  a  result  of  the  experiment  it  is  also  recommended  that  the  following  improvements  are  instigated  for  the  tools: 

1 1 .5.3  For  the  CAP/Atom  message  generator  the  following  additional  enhancements  are  recommended: 

•  Multi  language  support 
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•  Ability  to  set-up  and  run  alert  updates  (including  alert  changes  and  alert  cancels) 

•  Some  user  checks  for  when  publishing  messages  that  have  an  expiry  date  in  the  past 

•  Some  tidy  up  in  terms  of  the  user  interface,  size  of  fields  etc 

11.5.4  The  CAP/Atom  message  generator  tool  has  been  developed  as  an  open  source  tool  and,  as  mentioned  above 
some  work  has  been  performed  on  the  version  generated  by  this  CAUSE  project  to  support  subsequent  usage  by  the 
MASAS  National  Infrastructure  Team  to  add  a  basic  mapping  control.  However  there  is  some  work  to  be  done  to 
clean  up  the  code  and  make  additional  features  that  have  been  implemented  ready  for  more  public  release  to  the 
MASAS  development  community. 

11.5.5  For  the  MASAS  online  tools,  it  would  be  useful  to  provide  the  hub  administrator  with  the  ability  to  “flush”  the  hub 
i.e.  delete  all  messages  on  the  hub  at  a  given  instance.  This  would  save  considerable  time  resetting  the  environment 
after  running  in  test  data,  and  reduce  the  effort  needed  to  make  sure  message  pack  expiries  are  set  for  predicted 
reset  times. 

11.5.6  It  is  recommended  that  the  MASAS  event  types  are  augmented  with  a  “sensor  output”  type  perhaps  under  the 
“other”,  or  “infrastructure”  group  categories.  Providing  an  XML  tag  would  allow  users  to  filter  in  or  out  such  items. 
When  the  response  comes  from  an  automated  system,  such  as  a  sensor,  the  title  and  description  copy  should  clearly 
indicate  to  the  observer  that  they  came  from  an  automated  process  and  not  a  person.  Additionally,  give  that  this 
information  has  to  be  validated  the  alert  or  entry  should  indicate  a  low  level  of  certainty. 

11.5.7  It  is  recommended  that  a  study  is  undertaken  between  the  Ministry  of  Transportation,  UBC  and  Emergency 
management  regarding  an  effective  way  to  use  the  seismic  sensor  outputs  to  deliver  useful  information  in  the  context 
of  the  large  amount  of  triggered  events  that  are  likely  in  an  earthquake,  and  to  determine  how  that  might  by  pushed  to 
MASAS  and  presented  in  the  tools  such  as  to  BCeMap.  One  of  the  proposed  outputs  from  the  SIMS  system  is  an 
isoline  or  contour  map  of  ground  shake  intensity  derived  from  the  sensors.  If  this  could  be  pushed  to  BCeMap  e.g.  as 
a  time  series  of  WMS  snapshots  (relating  to  the  most  significant  aftershocks),  showing  where  the  most  intense 
shaking  has  taken  place  over  the  several  hours/days  after  a  major  earthquake.  Alternatively  each  sensor  could  have  a 
link  to  a  web  site  with  a  timeline  of  shaking  intensity  and  links  to  the  contour  maps  that  way.  As  above,  models  should 
indicate  low  level  of  certainty  when  automated  as  a  posting.  A  person  in  the  loop  can  raise  the  certainty  upon  review. 

1 1 .5.8  In  terms  of  the  BCeMap  refresh  rate  issue,  it  is  recommended  that  the  longer  term  solution  is  to  upgrade  BCeMap 
to  the  latest  Flex  viewer  and  use  the  MEFT  tools  (that  do  not  rely  on  the  current  BCeMap  Cache  and  therefore  to  pull 
information  in  real  time  off  the  MASAS  Hub).  In  the  mean  time  however  there  should  be  some  experimentation  with 
reducing  the  time  interval  between  the  FME  script  runs  in  the  scheduler  and  investigate  optimizing  the  process  to  run 
perhaps  as  frequently  as  every  5  minutes  (if  the  scripts  can  be  tuned  to  run  with  in  that  period).  If  there  is  an  issue 
with  running  the  scripts  sequentially  (i.e.  the  time  taken  is  too  long)  then  it  is  understood  that  separate  FME  processes 
can  be  run  in  parallel  at  the  same  time  to  speed  up  the  process.  Another  suggestion  is  to  give  a  clear  indicate  on 
screen  when  the  last  update  was  made  e.g.  a  timer  station  minutes  and  seconds  since  the  last  update. 

1 1 .5.9  A  symbol  set  for  the  information  update  events  are  needed  also,  so  that  the  user  can  see  what  has  been  updated 
recently,  this  needs  to  be  part  of  the  working  group  suggested  in  the  next  vignette  (international  Emergency 
Management  incident/operations/  infrastructure  taxonomy  and  associated  symbology).  Two  alternatives  are  being 
discussed:  1/  use  a  time  feature  that  shows  new  items  in  last  x  minutes/hours.  This  could  be  used  to  help  select 
information  for  situation  reports  and  brief  replacements  at  shift  changes,  or  2/  use  the  same  symbol  but  with  a 
background  inserted  if  new  in  last  x  minutes/hours. 
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12.  Vignette  5:  US  Transportation  Route  Investigation  -  Seattle  EOC 

12.1  Vignette  5:  Introduction 

12.1.1  The  Canadian  portion  of  the  experiment  was  conducted  in  parallel  with  a  similar  experiment  being  run  at  the 
PNNL  labs  in  USA,  who  were  also  trialing  their  own  set  of  technologies  for  this  experiment.  The  list  or  technologies 
they  were  using  is  detailed  in  their  project  report:  See  Reference  [1].  However  it  was  the  intention  that  at  least  two 
technologies  would  be  part  of  the  interaction  with  the  experiment  conducted  in  Vancouver.  These  were  intended  to  be 
‘Livewall’  and  SAMapper. 

12.1.2  Livewall  was  ultimately  not  operational  for  reasons  described  below,  however  SAMapper  was  used  to  capture 
several  pictures  and  events  of  traffic  incidents  in  the  Seattle  area  and  used  in  their  briefing  to  the  SW  PREOC 
regarding  the  state  of  highways  in  the  US.  The  SW  PREOC  was  able  to  see  both  the  SAMapper  application,  and  also 
the  events  appearing  in  BCeMap,  as  an  interface  from  SAMapper  to  MASAS/BCeMap  was  implemented. 

12.1.3  The  Android  mobile  device  software  was  also  demonstrated,  where  an  image  from  one  of  the  Canadian  venues 
was  taken  and  posted  up  to  the  SAMapper  dashboard,  which  could  then  be  seen  in  BCeMap. 

12.1.4  The  wider  process  of  identifying  potential  applications  for  integration  between  the  Canadian  and  US  parties, 
leading  to  this  vignette  is  described  in  Section  5.5. 

12.2  Vignette  5:  The  Technologies 

12.2.1  Livewall  was  a  video  conferencing  system  that  is  designed  to  allow  users  in  multiple  rooms  to  share  a  video  and 
interactive  desktop  session  using  a  touch  sensitive,  stand  mounted,  large  screen  that  had  a  transparent  overlay  of  the 
desktop  over  the  video  content  such  that  both  could  be  seen  at  the  same  time.  Interaction  between  ‘rooms’  could  be 
both  voice,  video  and  informational  content  at  the  same  time.  It  was  intended  to  use  this  technology  to  support  an 
interactive  dialogue  between  the  SWPREOC  and  the  PNNL  laboratory  and  the  discussion  around  the  state  of  the 
highways  around  the  Seattle  area. 

12.2.2  The  Livewall  components  for  the  SW  PREOC  (screen,  stand  and  Minimac)  were  delivered  to  Vancvouver  by  the 
PNNL  project  team  and  installed,  using  the  SFU  link  to  the  internet  via  the  microwave  radio  link  via  the  SFU  campus. 
This  took  some  setting  up  (ensuring  firewalls,  ports  and  network  connections  were  available,  and  this  did  work,  but 
with  some  intermittent  issues  regarding  the  video  sessions  that  involved  logging  off  /  shutting  down  and  rebooting 
components,  Other  tests  showed  a  fault  with  the  microphone  noise  cancellation  at  the  Seattle  end  and  the  delay  on 
the  voice  was  up  to  half  a  second  (causing  communication  to  be  a  little  stilted).  Before  the  experiment  was  executed 
the  hard  disk  on  the  Minimac  was  lost  and  could  not  be  recovered  so  the  Livewall  product  was  unfortunately  not 
operational  for  the  experiment  and  the  dialogue  focused  on  a  telephone  based  call. 

12.2.3  The  other  technology  called  SAMapper  (short  for  Situational  Awareness  Mapper)  was  built  by  a  PNNL 
development  team  on  Google’s  application  infrastructure  (appspot.com)  and  features  the  ability  for  mobile  devices 
such  as  Android  phones  to  take  photographs  of  incidents,  events  or  damage,  and  for  those  pictures  to  be  labelled  with 
some  information  and  pushed  into  the  application  dashboard. 

12.2.4  In  the  experiment,  a  number  of  images  were  pre-loaded  into  SAMapper  by  PNNL  for  the  scenario  (for  all  the 
incidents  around  Seattle),  but  also  a  copy  of  the  Android  SAMapper  smart  phone  application  was  shipped  to 
Vancouver  and  loaded  on  a  phone  being  used  by  one  of  the  experiment  coordinators  at  the  City  of  Vancouver 
Emergency  Operations  centre.  During  the  initial  briefing  for  the  day  a  picture  of  the  Vancouver  EOC  was  taken  with 
the  phone  and  posted  to  SAMapper  (see  image  in  the  next  section).  This  was  done  to  demonstrate  the  capability  and 
was  not  part  of  the  scenario. 

12.2.5  A  modified  version  of  the  CAP/ Atom  Message  Generator  was  implemented  that  was  able  to  call  a  web  service  on 
SAMapper  to  pull  all  the  current  messages,  drop  them  into  the  message  generator  and  re-publish  to  MASAS.  This 
was  manually  initiated  but  represented  the  essentials  of  an  integration  service  that  would  allow  such  tools  to  republish 
messages  into  the  MASAS  infrastructure  and  be  consumed  by  any  other  tool  that  can  draw  from  MASAS.  This 
represented  the  first  cross-border  experimental  interchange  of  alert  messages  using  MASAS,  illustrating  the  ease  with 
which  technically  these  components  can  be  integrated. 
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Figure  59  -  SAMapper  Integration  with  MASAS 


12.3  Vignette  5:  The  Action 

12.3.1  During  the  briefing  between  the  SWPREOC  and  the  Seattle  Emergency  Operations  Centre  (as  played  by  the 
group  at  the  PNNL  laboratories),  SAMapper  was  used  to  give  an  update  of  the  situation  on  the  highways  and 
immediate  vicinity  of  Seattle. 

12.3.2  The  events  and  images  in  SAMapper  were  available  via  the  SAMapper  screens,  and  also  via  the  MASAS 
interface  into  BCeMap.  When  Seattle  were  giving  their  brief  the  same  information  was  on  screen  at  the  SWPREOC  (in 
both  SAMapper  and  BCeMap). 
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Figure  60  -  SA  Mapper  Dashboard. 
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Figure  61  -  SA  Mapper  event  Image  Pop-up. 


12.3.3  The  following  images  are  the  same  events  as  they  appeared  in  BCeMap,  having  been  pulled  from  SAMapper  by 
the  message  generator  add-on  and  then  republished  to  MASAS. 
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Figure  62  -  SAMapper  Image  in  BCeMap 
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Figure  63  -  SAMapper  event  with  Bridge  Image 


12.3.4  The  Seattle  EOC  reported  that  although  there  were  several  impacts  in  the  area  and  this  particular  bridge  was 
collapsed,  the  major  highways  were  passable.  The  Seattle  EOC  was  asked  if  they  knew  of  the  state  of  the  highways 
north  towards  the  border,  but  they  advised  that  Whatcom  county  or  the  state  should  be  contacted  for  that  information 
-  this  set  the  scene  for  the  next  vignette. 

12.3.5  Separate  to  the  main  action,  and  just  as  a  demonstration  of  capability  the  following  image  was  taken  at  the 
Vancouver  EOC  via  the  Android  application  on  one  of  the  experiment  coordinator’s  Android  phone: 
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Figure  64  -  Vancouver  EOC  briefing  room  image 


r~ 

commercial 


June  21,.  2011,  9:35  AM 


Operational,  but  parttaEly  damaged  or  partially  in capacitated. 

Approx i  N  Skeena  5tr  Vancouver,  null  County 


Preparing  for  the  brief  at  VanEOC,  Daniel  has  hurt  his  finger.; 


Figure  65  -  Image  from  Vancouver  EOC  -  note:  Daniel’s  thumb  is  all  better  now. 


12.3.6  Again,  this  report  was  available  through  BCeMap  once 
MASAS/BCeMap.  See  Figure  66 


it  was  pulled 


from  SAMapper  and  pushed  to 
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Figure  66  -  SAMapper  Event  from  Vancouver  EOC  in  BCeMap 


12.4  Vignette  5:  Experimental  Findings 

12.4.1  Livewall  was  initially  well  received  when  installed  at  the  SW  PREOC.  A  number  of  the  managers  were  able  to  see 
the  system  in  action  when  it  was  first  set  up,  and  some  expressed  interest  in  the  possibility  of  having  such  systems  in 
all  five  PREOCs  for  communication  between  those  locations  and  the  PECC. 

12.4.2  The  teething  troubles  that  were  experienced  revealed  that  the  product  lacks  maturity  in  terms  of  handling  the 
various  issues  experienced.  In  particular  the  potential  network  capacity,  latency  and  packet  loss  performance  will 
always  be  an  issue  between  remote  locations,  and  there  should  be  diagnostic  or  error  handling  capabilities  that  would 
let  the  users  or  system  administrators  know  what  the  problems  might  be  if  the  system  is  not  performing  as  expected 
(e.g.  video  or  audio  streams  not  present,  as  was  experienced). 

12.4.3  The  SAMapper  application  proved  to  be  extremely  simple  and  quite  effective  for  a  mobile  device  reporting  and 
dashboard  tool.  The  application  to  generate  reports  on  an  Android  phone  installed  easily  and  worked  well,  and  it  was 
a  matter  of  a  few  hours  development  to  implement  an  interface  to  MASAS,  albeit  the  code  used  for  the  experiment 
was  not  production  quality  and  lacked  security.  Proper  mapping  between  the  SAMapper  codes  and  the  MASAS  codes 
would  also  be  required. 


12.5  Vignette  5:  Recommendations 

12.5.1  SAMapper  might  be  considered  as  a  low  cost  option  to  facilitate  reports  from  smart  phone  users  in  the  field. 
Further  investigation  would  be  required  into  the  overall  security  of  the  application  and  operational  procedures  around 
capturing,  classifying  and  retaining  images.  The  devices  carried  by  any  target  field  user  group  would  have  to  be 
assessed  and  whether  their  devices  are  supported.  The  solution  could  be  evaluated  against  use  of  Ushahidi  for  the 
same  purpose. 

12.5.2  It  was  demonstrated  that  it  would  be  technically  feasible  for  systems  in  the  US  to  be  connected  directly  (via  an 
adapter)  to  MASAS.  However,  as  US  systems  become  connected  to  IPAWS,  the  US  national  messaging  solution,  as 
detailed  in  the  next  section,  it  makes  more  operational  sense  for  Canadian  systems  to  receive  messages  from  US 
systems  via  IPAWS  and  MASAS,  otherwise  duplicate  messages  will  be  received. 
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13.  Vignette  6:  US  Transportation  Route  Investigation  -  Washington  Emergency 
Management  Department 

13.1  Vignette  6:  Introduction 

13.1.1  In  this  vignette,  having  established  the  state  of  the  highways  around  Seattle  and  that  they  are  passable,  the 
Operations  Director  at  the  South  West  PREOC  determines  that  it  is  necessary  to  discuss  the  state  of  other  highways 
running  East-West  across  the  state  and  North-South  immediately  below  the  border.  This  was  to  determine  if  the 
highways  might  allow  passage  of  resources  from  Osoyoos  down  into  the  United  States  and  back  up  into  Canada). 

13.1.2  A  dialogue  therefore  takes  place  between  the  SW  PREOC  and  the  Washington  State  Emergency  Management 
Department  (WA  EMD)  Emergency  Operations  Centre  that  is  located  on  Camp  Murray  near  Tacoma. 

13.1.3  This  dialogue  was  recorded  subsequent  to  the  main  experiment  day  by  telephone,  and  recorded  using  a 
conference  bridge  with  the  film  studio. 

13.2  Vignette  6:  The  Technologies 

13.2.1  To  support  this  dialogue  an  interface  between  official  United  States  and  Canadian  alerting  message  infrastructure 
was  established  as  illustrated  in  Figure  39.  i.e.  an  interface  from  an  instance  of  the  MyStateUSA  system  in  the  states, 
through  I  PAWS  to  MASAS  and  then  to  BCeMap.  These  components  are  described  in  more  detail  in  section  6. 


British  Columbia 
eMAP 


MASAS 


1*1 


I 


IPAWS-JITC  P 
Canadian  COG 


Canada  /  US  Border 


Washington 
State  EMD 
MyStateUSA 


^SYSTEM  CONSOLE 


Figure  67  -  US/Canadian  alerting  infrastructure  connection 


13.2.2  The  Joint  Interoperability  Test  Command  JITC  (JITC)  is  a  division  of  the  Defence  Information  Systems  Agency 
that  supports  the  FEMA  Integrated  Public  Alert  and  Warning  System  (IPAWS)  program.  This  group  tests  the 
interoperability  of  alert  and  warning  equipment,  and  they  provided  access  to  a  test  instance  of  IPAWS  for  the 
purposes  of  the  experiment. 

13.2.3  A  Common  Operating  Group  (COG)  specific  to  Canada  was  created  such  that  test  messages  could  be  received 
from  and  pushed  to  IPAWS  by  MyStateUSA  and  the  messages  could  then  flow  to  and  from  the  Canadian  MASAS  hub 
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using  addressing  specific  to  that  COG. 

13.2.4  To  develop  the  interfaces  illustrated  in  Figure  67,  the  developers  at  MyStateUSA  worked  to  build  interfaces  to  the 
IPAWS-JITC  instance  to  both  publish  and  consume  messages.  In  parallel  the  MASAS  National  infrastructure  team 
implemented  a  VPN  connection  to  the  JITC-IPAWS  instance  and  implemented  code  that  was  able  to  move  messages 
between  JITC-IPAWS  and  MASAS.  Due  to  time  constraints,  there  were  still  manual  elements  to  this  process  (i.e. 
initiating  a  push  or  a  pull  between  the  hubs)  but  the  mapping  and  translation  of  messages  and  codes  for  the  sample 
set  of  messages  was  set-up  and  the  ice  was  broken  in  terms  of  international  alert  messages.  The  technical  details  of 
the  set-up  were  as  follows. 

13.2.5  Connecting  to  MASAS  was  secured  via  an  HTTPS  connection  that  could  be  made  from  any  internet  connected 
host.  MASAS  employs  a  REST  API  based  on  AtomPub  to  send/receive  information.  Connecting  to  JITC-IPAWS  was 
secured  via  a  Cisco  software  VPN  system.  JITC-IPAWS  employs  a  SOAP  API  with  specific  header  and  message 
body  handling  to  send/receive  information. 

13.2.6  Software  was  created  to  automate  the  sending  and  receiving  of  information  for  both  systems.  The  MASAS  script 
provided  the  ability  to  download  any  Entries  that  had  been  posted  in  I  PAWS  since  an  entered  time  value  and  deposit 
them  into  a  directory  as  individual  CAP  messages  in  MASAS.  In  addition  to  downloading  these  messages,  the  script 
also  had  an  upload  function  that  could  post  an  individual  CAP  message  to  MASAS.  The  JITC-IPAWS  script  had  very 
similar  functionality  to  both  download  and  upload  individual  CAP  messages. 

13.2.7  In  order  to  fully  bridge  the  two  systems  some  manual  steps  were  necessary.  Once  a  message  was  downloaded 
from  JITC-IPAWS,  and  prior  to  uploading  to  MASAS,  some  changes  to  the  CAP  message  were  necessary.  An 
attempt  to  add  CAP-CP  Profile  elements  in  place  of  CAP-IPAWS  to  the  messages  was  being  made  by  MyStateUSA, 
however  there  were  still  CAP-CP  issues  which  would  have  caused  rejection  of  the  message.  These  errors  were 
corrected  manually.  Values  for  <event>,  <eventCode>,  and  <geocode>  were  changed.  Once  these  changes  were 
made,  the  MASAS  script  was  employed  to  post  the  message. 

13.2.8  After  downloading  a  message  from  MASAS  and  prior  to  uploading  to  JITC-IPAWS,  changes  were  also  necessary 
to  the  CAP  message.  Due  to  the  fact  that  JITC-IPAWS  was  still  in  development,  different  changes  were  required 
depending  on  the  day  a  posting  occurred.  Typically  the  changes  involved  removing  all  CAP-CP  Profile  elements  from 
the  message  and  adjusting  the  <sent>  and  <expires>  time  values  to  meet  the  very  stringent  requirements  that  JITC- 
IPAWS  imposed.  Once  the  changes  were  made,  the  JITC-IPAWS  script  was  employed  to  post  the  message. 

13.2.9  Development  of  the  MASAS  and  JITC-IPAWS  automation  scripts  was  relatively  quick,  based  on  the 
documentation  provided.  A  serious  challenge  was  posed  by  the  VPN  system  used  to  secure  JITC-IPAWS  however, 
which  prevented  any  testing  of  the  JITC-IPAWS  script  against  a  live  environment  until  a  few  days  prior  to  the  live 
event.  The  VPN  software  used  an  older  SSL  certificate  that  many  modern  browsers  considered  too  old  and  insecure 
to  be  valid  and  so  rejected  any  attempts  to  connect.  After  some  experimentation  a  custom  Windows  XP  build  was 
created  to  connect  to  the  VPN,  however  once  successful  connections  were  made,  stability  problems  were 
encountered  with  the  VPN  dropping  the  connection  at  random  times.  Due  to  these  VPN  issues,  not  enough  testing 
took  place  beforehand  to  provide  the  feedback  MyStateUSA  required  to  fix  the  CAP-CP  issues,  nor  to  work  on  an 
automated  method  to  correct  the  messages  as  part  of  the  exchange,  and  so  a  manual  method  was  adopted. 

13.2.10  JITC-IPAWS  was  also  being  actively  developed  at  the  time  and  was  not  a  stable  system.  During  some  test  runs 
early  on,  CAP-CP  Profile  messages  were  accepted.  However  later  attempts  to  send  CAP-CP  messages  were 
rejected.  The  error  messages  provided  by  JITC-IPAWS  were  sometimes  cryptic  and  difficult  to  understand  which 
made  diagnosing  these  errors  time  consuming. 

13.2.11  The  eventCode  list  used  by  the  CAP-IPAWS  Profile  also  posed  a  challenge.  It  is  a  very  limited  set  of  events  and 
does  not  translate  well  to  CAP-CP  events.  While  the  geospatial  elements  of  CAP,  polygon  and  circle,  resolved  any 
translation  issues  between  different  geocode  elements  used  by  the  two  CAP  profiles,  there  is  no  universal  translation 
for  eventCodes. 

13.2.12  The  scenario  was  developed  around  some  specific  incidents  in  the  Northern  end  of  the  states  on  the  15  at 
Ferndale,  Dakota  Creek  and  at  the  border  crossing.  Similarly  the  events  just  north  of  the  border  were  transmitted  to 
MyStateUSA  i.e.  an  industrial  fire  in  White  rock,  traffic  congestion  on  the  Alex  Fraser  Bridge  and  the  closure  of  the 
Massey  tunnel. 

13.3  Vignette  6:  The  Action 
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13.3.1  The  images  of  the  events  in  the  respective  systems  are  as  follows.  Figure  68  shows  a  screen  in  MyStateUSA  for 
a  message  sent  from  MyStateUSA  and  the  map  representation  in  Figure  69. 
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Figure  68  -  Message  sent  from  MyStateUSA 


■  mystateusa.com 


System  console 

Jurisdiction  Name:  Washington  Emergency  Management  (672) 
Signed  in  as:  eiones  (Elysa  Jones) 


Figure  69  -  Map  view  of  Messages  sent  from  MyStateUSA 


13.3.2  Their  representation  in  BCeMap  (once  they  are  sent  from  MyStateUSA  to  IPAWS  to  MASAS  and  then  to  BCeMap 
is  shown  in  Figure  70. 
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08T00 : 00 : 00-07 : 00 

•  headline:  TEST  Bridge  closed 
over  Dakota  Creek  on  Hwy  5 
south  of  Blaine  TEST 

•  language;  en-CA 

•  profile_CAP-CP_Event: 
bridgeClose 

'  •  profile_CAP-  CP_Locat: 
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Figure  70  -  BCeMap  representation  of  alerts  from  MyStateUSA 


13.3.3  The  screen  in  Figure  71  also  shows  the  messages  sent  from  BCeMap  to  MyStateUSA  (the  messages  North  of  the 
border,  including  the  closure  to  the  Massey  Tunnel,  traffic  congestion  on  the  Alex  Fraser  bridge  and  the  industrial  fire 
in  White  Rock: 
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13.4  Vignette  6:  Experimental  Findings 

13.4.1  Support  for  this  vignette  was  strong  from  the  participants,  and  there  was  some  excitement  about  seeing  alert 
messages  pass  between  the  two  official  alerting  hubs  of  the  countries  for  the  first  time.  This  was  a  considerable 
achievement  considering  the  technical  and  political  hurdles  that  were  overcome. 

13.4.2  The  ability  for  neighbouring  agencies  to  be  aware  of  the  state  of  highways  and  incidents  at  any  given  moment 
without  the  need  for  a  formal  situation  report  (and  all  the  filtering  that  process  involves)  or  direct  telephone 
communication  with  the  right  individuals,  was  deemed  enormously  powerful,  especially  between  areas  that  are 
geographically  very  close,  but  politically  and  organizationally  very  separate. 

13.4.3  The  original  plan  at  the  US  end  was  to  use  the  production  IPAWS-OPEN  platform  however;  FEMA  IT  would  not 
allow  foreign  access  citing  DHS  security  rules.  An  equivalent  implementation  of  IPAWS-OPEN  which  resides  at  the 
JITC  was  used  for  the  development,  testing  and  execution  of  message  exchanges  during  the  experiment,  consistent 
with  use  of  test  instances  on  the  Canadian  end. 

13.4.4  The  MyStateUSA  team  identified  what  would  be  needed  to  implement  the  symbology  and  profiles  fully  in  the 
MyStateUSA  system.  However  time  schedule  and  resources  were  not  available  to  complete  a  full  implementation  of 
this  for  the  experiment.  However,  forms  were  developed  for  the  specific  messages  needed  for  the  exchanges. 
MyStateUSA  has  determined  that  they  are  prepared  to  fully  implement  the  CAP-CP,  event  location  layer  and  Canada 
symbology  if  required  by  subsequent  projects.  The  company’s  management  is  committed  to  allocate  resources  to 
make  this  upgrade  as  they  value  the  opportunity  to  support  the  sharing  of  data  across  international  borders  using 
open  standards.  11 


13.5  Vignette  6:  Recommendations 

13.5.1  It  is  recommended  that  a  project,  or  projects  are  established  to  engage  working  groups  that  span  the  border  to 
develop  the  governance,  operational  procedures,  technology,  training/exercises  and  real  usage12  that  would  allow 
alerts  to  cross  the  border.  These  projects  should  consider  what  systems  generate  messages,  under  what  context, 
what  do  they  mean  to  whom,  and  what  mappings  are  required  between  the  codes  in  different  systems. 

13.5.2  A  number  of  cross  border  pilots  are  being  planned,  several  involving  NIEM  messaging  to  police  the  relevant 
information  sharing,  and  at  least  one  pilot  that  might  involve  sharing  bio-alerts  on  health  related  outbreaks  (e.g.  H1N1, 
SARS  etc.).  Other  areas  of  interest  to  the  DHS  S&T  sponsors  of  this  project  include  suspicious  activity  reports 
involving  movement  of  cash  across  the  border  or  human  trafficking. 

13.5.3  These  projects  should  include  some  elements  aimed  at  implementing  pilot  operational  integrations,  for  example  a 
production  version  of  the  MyStateUSA  (implemented  at  WEMD)  to  BCeMap  connection,  via  production  versions  of 
IPAWS/MASAS.  The  project  could  also  look  at  technical  issues  in  terms  of  how  the  use  of  CAP  with  EDXL-DE13  (i.e. 
EDXL-DE  as  a  wrapper  for  CAP)  could  be  used  to  make  it  NIEM  compliant  and  could  be  used  to  better  manage 
distribution  of  feeds  coming  north  into  Canada  and  vice  versa. 

13.5.4  The  project  above  should  be  established  to  work  with  the  senior  execs  and  similar  project  initiatives  at  FEMA 
IPAWS,  NIEM  PMO  (National  Information  Exchange  Model  Program  Management  Office)  and  the  PM  ISE  (Program 
Manager  for  the  Information  Sharing  Environment)  organizations. 

13.5.5  It  is  understood  that  this  CAUSE  project  has  raised  the  profile  of  this  initiative  and  the  security  obstacle  with 
FEMA  IT  has  been  resolved.  A  stipulation  in  one  of  the  Policy  documents  has  been  re-interpreted  such  that  interface 
with  another  nation  can  be  allowed.  The  experiment  broke  the  ice  but  policy  hurdles  remain. 

13.5.6  A  Memorandum  of  Understanding  (MOU)  was  agreed  with  the  US  counterparts  to  demonstrate  the  MASAS<> 
IPWAS  connection.  Two  other  MOUs  have  also  now  been  signed  to  progress  the  technical  and  operational  aspects  of 
the  connection.  High  level  governance  needs  to  be  addressed  in  terms  of  a  master  working  group  that  can  provide 
governance,  monitor  and  coordinate  between  the  cross  border  pilots,  ensuring  consistent  approaches  and  can 
address  an  international  EM  incident/operations/  infrastructure  taxonomy  and  associated  symbology. 


11  Source:  Summary  report  of  project  involvement  from  Elysa  Jones  (Alert  Sense  consultant). 

Governance,  Standard  Operating  Procedures,  Technology,  Training/exercises  and  usage  are  the  Interoperability  Continuum  Elements  promoted  by 

the  DHS  Safecom  program  to  assist  agencies  and  policy  makers  to  implement  interoperability  solutions. 

1 3 

EDXL-DE  stands  for  Emergency  Data  Exchange  Language  -  Distribution  Element.  An  OASAS  standards  track  describing  a  standard  message 
distribution  framework  for  data  sharing  among  emergency  information  systems 
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13.5.7  Further  development  of  the  IPAWS/MASAS  interface  should  be  included  in  the  next  experiment. 

13.5.8  While  the  exercise  involved  simulated  information,  MASAS/IPAWS  experiments  exposed  CAP  quality  issues  from 
the  U.S.  National  Weather  Service  that  we  understand  are  being  worked  on. 

13.5.9  In  order  to  provide  an  operationally  ready  exchange  of  information  between  MASAS  and  JITC-IPAWS,  further 
work  is  necessary.  The  JITC-IPAWS  interface  needs  to  reach  a  stable  level,  both  in  the  method  used  to  secure  the 
connection  to  the  system,  i.e.  preferable  a  redundant  private  IP  network  connection,  not  a  VPN,  and  also  stability  in 
the  methods  used  to  upload  and  download  messages.  A  key  requirement  is  that  JITC-IPAWS  should  accept  a  CAP 
message  with  CAP-CP  Profile  elements  and  any  CAP  requirements  that  are  being  imposed  on  a  system  wide  basis 
should  not  be  specific  to  CAP-IPAWS  only.  These  requirements  should  apply  only  if  the  CAP  message  is  identified  as 
CAP-IPAWS.  Messages  sent  by  US  systems  should  not  substitute  CAP-CP  for  CAP-IPAWS  in  their  messages 
destined  for  cross-border  exchange.  MASAS  supports  CAP-IPAWS  natively.  If  a  US  based  system  does  support 
CAP-CP,  it  should  publish  the  message  in  both  Profiles  rather  than  switch  between  the  two. 

13.5.10  The  MASAS  interface  needs  to  develop  methods  to  address  messages  based  on  the  COG  ID's  used  by  JITC- 
IPAWS.  This  will  be  challenging  because  the  addressing  of  messages  is  contrary  to  how  MASAS  currently  operates. 
Some  possible  solutions  are  a  subscription  based  method  for  JITC-IPAWS  systems  to  identify  their  COG  ID  and  area 
of  interest,  or  a  general  delivery  MASAS  COG. 


13.5.1 1  Finally  the  translation  of  eventCodes  between  systems  needs  to  be  addressed.  CAP-CP  provides  a  very  detailed 
list  of  events  while  CAP-IPAWS  is  limited.  Direct  translation  between  the  two  is  not  possible  for  many  of  the  events 
that  could  take  place  during  an  emergency.  A  likely  solution  is  to  expand  the  CAP-IPAWS  eventCode  list,  or  to 
develop  a  shared  eventCode  list  that  is  not  Profile  specific  but  can  be  included  in  CAP  messages  to  ease  translation 
between  more  localized  eventCode  lists. 
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Appendix  A  -  The  BCeMap/MASAS  Integration  Development  Project. 


BCeMap  is  British  Columbia’s  situational  awareness  and  emergency  mapping  system.  Through  development 
funded  by  GeoConnections  in  2009/2010  the  system  was  build  by  ESRI  and  hosted  at  GeoBC  on  behalf  of 
Emergency  Management  BC  who  is  the  main  sponsor.  The  system  is  currently  in  production  for  use  by  the 
Provincial  Emergency  Operations  centres  and  brings  together  over  60  static  layers  together  with  several  dynamic 
data  feeds  to  present  a  single  browser  based  map  for  users,  using  the  state  of  the  art  ArGIS  flex  tools  developed 
by  ESRI. 


Static  Layers 

BC  Healthcare  facilities 
Communications  Infrastructure 
Oil  and  Gas  facilities 
Water  Wells 
Points  of  Diversion 
GVRD  Reservoirs 
Municipal  Waste  Facilities 
GVRD  Sewage  Treatment  Plants 
Municipal  Sanitary  Sewage  Lines 
Municipal  Water  Utility  Lines 
Municipal  Drainage  -  Storm  Lines 
BC  Hydro  Facility  Points 
BC  Hydro  Facility  Footprints 
BC  Transmission  Corp  Transmission  Lines 
Place  Names 
Municipalities 
Regional  Districts 
Police  Jurisdiction  Boundaries 
Fire  Protection  District  Boundaries 
Federal  Electoral  Districts 
Provincial  Emergency  Program  Boundaries 
Local  Health  Areas 
Health  Service  Delivery  Areas 
Health  Authority  Boundaries 
BC  Wildfire  -  Fire  Zones 
BC  Wildfire  -  Fire  Centres 
First  Nation  Reserves 
Public  Buildings 
Present  Land  Use 
Emergency  Operations  Centres 
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Disaster  Response  Routes 
Disaster  Response  Zones 
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Skytrain  Stations 
Transit  Exchanges 
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Westcoast  Express  Lines 
Digital  Road  Atlas 
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Figure  72  -  BCeMap  Architecture 


Figure  6  shows  the  architecture  of  BCeMap,  how  the  static  layers  and  wild  fire  (from  Ministry  of  Forests  and 
Range)  feeds  are  served  up  from  the  Land  and  Resource  Data  Warehouse  together  with  feeds  from  Drive  BC, 
Environment  Canada  Weather,  NRCan  Earthquakes,  incidents  from  E  Team  (the  provincial  incident  management 
system,  and  also  a  data  feed  from  the  original  pilot  version  of  MASAS  (MASAS  1). 


Figure  73  is  a  screenshot  of  BCeMap  showing  the  earthquakes  in  the  province  over  a  period  of  several  weeks. 
Most  of  which  are  normally  less  than  a  Magnitude  2.  A  few  are  large  but  rarely  occur  near  populated  areas. 
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Figure  73  -  BCeMap  Earthquakes  feed. 

For  the  CAUSE  experiment,  it  was  determined  fairly  early  on  that  a  change  to  the  newer  MASAS  II  feed  was 
required  to  enable  MASAS  II  to  be  the  core  integration  platform  for  the  technologies  to  be  used  in  the  experiment. 
The  MASAS  1  feed  was  to  be  deprecated  and  the  MASAS  II  feed  used  Atom  as  the  delivery  mechanism  for  the 
CAP-CP  messages.  An  upgrade  was  therefore  deemed  necessary. 

Several  options  were  considered  for  the  upgrade,  including  the  adoption  of  the  open  source  MASAS  ESRI  Flex 
Tools  (MEFT)  developed  by  the  MASAS  National  Infrastructure  Team,  for  the  consumption  and  publishing  of 
MASAS  messages  on  such  a  platform.  However  one  significant  issue  was  that  the  MEFT  are  build  to  the  Flex  Api 
version  2.2  and  BCeMap  is  still  based  on  version  1 .3  (at  the  client  end)  and  also  the  server  side  ArGIS  versions 
would  need  to  be  upgraded  also.  The  upgrade  of  BCeMap  to  these  later  versions  was  costed  and  deemed  too 
high  a  cost,  risk  and  timeline  to  support  this  approach  for  the  CAUSE  experiment. 

Therefore  a  lower  cost  and  lower  risk  approach  was  determined  i.e.  the  development  of  a  new  FME14  script  to 
process  the  MASAS  II  messages  and  convert  to  the  standard  BCeMap  cache  format  for  serving  up  to  the 
application  in  the  same  manner  and  using  the  same  user  interface  tools  as  the  other  feeds. 

Planetworks  contracted  a  developer  with  FME  experience  to  implement  the  MASAS  II  feed.  The  script  was 
developed  on  a  partial  platform  at  Planetworks  (including  an  Oracle  database  constructed  to  emulate  the  BCeMap 
database),  and  deployed  to  the  development  platform  at  ESRI. 

ESRI  was  contracted  to  upgrade  user  interface  configurations  to  support  the  replacement  of  the  MASAS  I  display 
with  the  MASAS  II  controls.  The  opportunity  was  also  taken  to  upgrade  the  user  interface  controls  to  allow  filtering 
of  the  events  on  display  based  on  data  in  the  messages  such  as  date  of  message  update,  status,  event  type,  and 
combinations  of  those  data  fields,  to  give  users  more  control  of  what  they  see.  In  addition  the  zoom  controls  were 
changed  such  that  click  and  double  click  of  the  events  in  the  list  provided  a  configurable  level  of  zoom. 

These  changes  were  all  delivered  by  ESRI  and  tested  with  the  new  FME  script  and  then  packaged  by  ESRI  for 
deployment  on  the  delivery  platform  at  GeoBC. 

A  number  of  issues  were  encountered  at  GeoBC  with  the  deployment  processes  and  platforms  including: 

-  some  challenges  configuring  the  security  gateway 


14  FME  is  a  state-of-the  art  GIS  Extract  Transform  and  Load  (ETL)  toolset  developed  by  Safe  Software  for  transforming 
data  messages  from  one  format  to  another  and  includes  the  ability  to  convert  data  from  web  service  calls  to 
database  format.  It  is  used  for  the  other  dynamic  feeds  to  convert  to  the  BCeMap  Cache. 
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-  some  restructuring  was  required  to  cleanly  separate  services  between  the  three  hosted  platforms 
(delivery,  test  and  production). 

-  a  separately  sponsored  upgrade  to  the  security  gateway  on  the  delivery  platform  disabled  the 
application  (this  was  reversed  out  for  the  duration  of  the  experiment) 

-  the  failure  of  the  Bing  maps  token  service  through  ESRI  which  disabled  the  base  map  services 

-  the  discovery  that  the  BCeMap  database  cache  only  supported  a  coordinate  range  that  spanned  from  a 
line  extended  from  the  Eastern  border  of  Alaska,  to  the  Eastern  border  of  Alberta  and  from  a  part  of  the 
states  just  south  of  Tacoma  up  to  a  latitude  above  the  North  West  territories.  This  constraint  was  put  in  to 
the  BCeMap  database  when  originally  deployed  to  match  the  Land  Resource  Data  Warehouse  standard 
(which  includes  milli-metric  accuracy  and  hence  this  geographic  limitation  in  order  for  the  database  server 
operating  system  to  cope).  When  the  earthquake  messages  were  passed  in  through  MASAS  that  were 
further  south  than  allowed,  an  error  would  be  thrown  on  the  feed  supplying  the  user  interface.  A 
temporary  filter  was  implemented  in  the  FME  script  to  prevent  the  error  for  the  duration  of  the  experiment. 

The  issues  above  were  resolved,  deployment  was  successfully  completed  and  tested  such  that  all  functionality 
needed  for  the  experiment  was  in  place  for  the  execution  date  of  21st  June. 

Test  pack  messages  were  generated  using  the  CAP-CP/Atom  Message  generator  that  was  developed  to  support 
the  scenarios  in  the  project.  Conducting  the  experiment  itself  went  a  long  way  towards  testing  the  respective  tools 
(both  the  generator,  the  FME  script  and  the  user  interface  presentation).  A  number  of  resilience  issues  were 
exposed  regarding  the  FME  script  and  threes  are  being  corrected  as  part  of  the  leave-behind  for  the  project  (for 
example  resilience  to  strange  characters  that  can  be  experienced  by  users  copying  and  pasting  text  sections  from 
web  pages).  This  particular  fix  is  also  being  implemented  on  the  E  Team  FME  feed  script  which  also  experiences 
the  same  issue.  Ability  to  handle  multiple  text  blocks  in  MASAS  messages  is  also  being  added,  for  example  the 
French  sections. 

A  direct  feed  of  NRCan  earthquake  messages  was  attempted  in  the  week  leading  up  to  the  experiment  execution, 
however  there  was  insufficient  time  to  add  the  multi  text-block  handling  for  the  actual  execution  and  these 
messages  were  emulated  using  the  CAP/ Atom  message  generator  instead. 

In  addition  2  WMS  feeds  were  implemented  from  the  following  sources:  an  ArGIS  server  WMS  feed  of  the  static 
layers  output  by  Hazus-MH  for  the  Richmond  Cascadian  Subduction  zone  damage  assessment  and  also  for  the 
EmerGeo  Fusionpoint  WMS  output  of  incidents.  There  were  both  successful  in  implementing  a  visual 
representation  in  BCeMap  although  both  sources  would  need  some  development  work  to  be  fully  implement. 

Such  developments  would  be  avoided  through  use  of  MASAS  for  such  feeds  instead. 

Subsequent  to  the  experiment  further  User  Acceptance  Testing  (UAT)  on  the  event  filter  tools  has  also  been 
executed  and  issues  raised  on  ESRI. 

All  fixes  to  the  components,  and  the  change  to  the  database  cache  coordinate  range  (which  has  been  escalated 
through  change  request  to  the  respective  authorities  in  GeoBC)  are  being  scheduled  for  deployment  in  late 
August  or  early  September  to  complete  the  CAUSE  project  leave-behind  and  close-out  the  project. 

The  experiment  has  shown  that  BCeMap  can  be  an  effective  means  for  information  to  be  brought  together  and 
shared  with  others  as  part  of  the  general  emergency  management  infrastructure  in  BC.  It  is  able  to  pull  together 
information  from  multiple  sources  including  WMS  sources  and  now  all  data  feeds  available  through  MASAS  II. 

As  more  layers  are  added  and  as  MASAS  becomes  more  enriched  with  new  feed  sources  (e.g.  recently  the 
NRCan  earthquake  feed  and  the  BC  Hydro  power  outage  data  overlay)  then  BCeMap  will  become  more  relied  on 
especially  as  it  is  rolled  out.  Currently  the  application  is  only  available  to  Emergency  Management  BC  users  in  the 
provincial  Emergency  Operations  Centres,  however  the  medium  to  longer  term  plan  is  to  make  available  to 
municipal  jurisdictions. 

As  dependency  increases  then  it  is  recommended  that  the  resiliency  of  this  component  is  increased  accordingly. 
The  application  is  currently  hosted  out  of  a  single  hosting  facility  in  Victoria  which  is  close  to  the  likely  areas  of 
seismic  activity  in  case  of  a  major  Cascadian  Subduction  zone  event. 
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One  key  recommendation  therefore  is  to  enhance  the  resilience  of  the  application  to  ensure  continuity  of  service. 
A  full  Service  Level  Agreement  has  not  yet  been  agreed  for  BCeMap  with  the  hosting  organization.  It  is 
understood  that  the  current  facility  is  based  in  Victoria,  has  24  hour  security,  is  hosted  on  servers  with  dual 
Network  Interface  Cards  (NICs),  Backup  Power  supply  and  SAN  storage,  with  off-site  backup  although  no 
redundant  site  facility  at  present.  There  are  discussions  taking  place  as  part  of  the  Service  Level  Agreement 
development  regarding  moving  the  application  to  the  Client  Services  Natural  Resources  (CSNR)  data  centres 
based  in  Calgary  (delivery/test)  and  Kamloops  (production)  which  are  now  taking  orders.  Windows  servers  in 
these  locations  are  running  VMWare  on  clustered  servers  and  hence  will  be  more  resilient. 

It  is  recommended  that  a  strategy  for  implementing  a  dual  redundant  location  at  an  alternate  site,  ideally  with  load 
balancing  and  failover  to  the  other  site  in  the  case  of  the  failure  of  one  site  or  its  connectivity. 

There  may  be  a  cost  to  enhancing  the  application  to  perform  in  this  manner  both  in  terms  of 
developing/implementing  on  the  redundant  architecture  and  potentially  an  increased  support  costs  due  to  the 
higher  specification  platform. 

One  strategy  to  offset  this  cost  would  be  to  partner  with  another  Province  who  may  be  interested  in  a  similar 
concept  (Common  Operating  Picture)  and  the  same  technologies  (ArcGIS  /  Oracle).  Another  would  be  to  partner 
with  E-Comm  who  have  a  very  similar  application  (E2MV)  which  uses  the  flex  API  and  ArcGIS  server,  albeit  on 
the  SQL  server  platform. 

Alignment  of  the  platforms  and  support  services  between  two  partners  is  likely  to  deliver  some  cost  savings 
assuming  development  requirements  from  the  respective  user  bases  is  in  line  but  that  may  be  offset  by  the  higher 
costs  of  supporting  dual  redundant  infrastructures. 

Another  recommendation  is  also  to  upgrade  the  BCeMap  user  interface  to  the  latest  version  (with  the 
corresponding  server  side  upgrade)  such  that  the  open  source  MASAS  controls  can  be  leveraged  especially  the 
MASAS  publishing  tool  (not  currently  supported  in  BCeMap)  and  also  WMS  feeds  can  be  consumed  natively  in 
the  BCeMap  user  browser  (currently  these  data  sources  have  to  be  consumed  by  the  server  and  served  up  to  the 
client  as  a  map  service.  The  current  arrangement  is  not  the  most  performant  solution). 

Another  potential  issue  as  the  application  expands  and  the  number  of  information  layers  it  supports  grows  is  the 
ease  with  which  the  application  can  be  navigated  by  users.  Additional  layer  search  and  selection  functionality  may 
be  required  (e.g.  if  multiple  threat  scenarios  are  supported  by  the  WMS  feature,  or  multiple  feeds  from  municipal 
Incident  Management  systems,  then  finding  the  appropriate  layers  for  display  may  be  a  challenge  and  some  more 
advanced  characterization  (meta  data)  with  respect  to  each  layer  and  user  search/filter  facility  on  the  layers  may 
be  required. 

Therefore  recommended  investment  approach  to  increasing  resilience  is  to  set  up  a  project  to  cost,  plan  and 
promote  the  initiatives  described  above  i.e. 

-  Dual  redundant  resilience  and  load  balancing 

-  Upgrade  to  Flex  Api  2.2  and  ArGIS  server  10.1 

-  Investigation  of  integration  of  the  MEFT  tools,  also  the  user  facilities  to  support  feeds  from  multiple  CAUSE 
hubs. 

-  More  advanced  layer  search  and  selection  facilities. 
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Appendix  B  -  Detailed  script  used  for  guiding  the  two  sessions  and  the  filming 


Morning  Session 


Scenario 

Experiment 

Locations 

CAUSE  Experiment  Script  Execution  -  Morning  session 

Technologies  at  play: 

Otherfilmingatsame  time 

Timeline 

Timeline 

involved 

N/A  (overview  9.30 
of  all  events) 


9:30  am  -  Experiment  Briefing:  Run  through  of  the  overview  and  goals  of  the  experiment,  and  goals  for  the  day,  I  will  then  run  through  the  CAP/Atom  message 
earthquake  scenario,  presented  using  some  of  the  tools  which  will  set  the  scene  for  what  happened  i.e.  An  M9.0  earthquake  at  8am  on  21st  generator  /  MASAS/ 
June  off  the  coast  of  Oregon,  with  damage  created  over  a  number  of  communities  in  the  lower  mainland  and  on  Vancouver  Island,  followed  BCeMap 
by  tsunami  warnings/alerts  to  coastal  BC,  a  further  aftershock  happens  an  hour  later,  magnitude  7.1,  the  damage  to  the  lower  mainland  BC 
is  not  expected  to  be  massive  however  the  main  event  and  some  more  local  aftershocks  will  cause  debris,  power,  communications  and 
transportation  disruption  in  most  of  the  communities.  In  the  South  and  West  of  the  lower  mainland  there  will  be  several  hundred  buildings 
with  minor  to  moderate  damage,  some  ruptured  gas  mains  and  ensuing  fires,  some  bridges  may  be  determined  to  have  exceeded  their 
design  limits,  rock  falls  etc. .  Some  power  supplies  will  be  disrupted  through  falling  power  lines  and  communications  affected  accordingly. 

There  are  several  rockslides  including  in  the  Fraser  Valley  Canyon  and  on  the  highway  up  to  Squamish.  More  detail  is  included  in  the 
vignettes  described  below.  The  briefing  will  be  an  overview  of  the  scenarios  and  the  technologies  to  set  the  scene  for  the  day. 


Earthquake  +  1 

24  hours 
Vignette2  vl 
(4hrs)  + 
Vignette2  vl 
step  20  (8hrs)  + 
Langley  + 
MystateUSA 
Messages 


SWPREOC  10:00- We  will  be  acting  out  some  dialogue  here  in  the  SWPREOC  to  represent  the  process  of  getting  a  regional  roll-up  of  the  overall  BCeMap 

situation  involving  the  different  sections:  getting  up  to  speed  with  the  situation  and  determining  affected  areas,  declarations,  status  of  Cl, 
access  routes,  potential  impact  on  population  etc.  This  would  represent  the  summary  of  various  incidents/events  /  damage  over  a  24  hour 
period.  Assess  the  situation  regarding  the  rock  falls  in  the  Fraser  valley  and  determine  that  there  is  a  need  for  investigating  the  ability  to 
bring  resources  to  the  lower  mainland  from  interior  BC  via  the  US  (this  sets  up  the  call  to  Seattle  and  then  to  the  WA  EMD). 

Damage  in  Langley  can  be  brought  into  this  one  . .  (Doug  will  inject  as  part  of  scenario  introduction) 


City  of  Vancouver  Ushahidi  reports  being  created  and  311  Ushahidi  / 

EOC/311  team  analysing  Ushahidi  reports  and  ETEam 

creating  ETeam  call  centre  reports.  The 
significant  ones  being  the  reports  and 
pictures  relating  to  the  Georgia  Viaduct 
collapse. 


Earthquake  + 
26  hours 


SWPREOC  /  10:30- At  the  SWPREOC*  over  a  video  conferencing  tool  called  Livewall,  we  will  receive  a  situation  report  from  the  Seattle  area  and  then  Livewall,  SA  Mapper, 

Seattle  EOC  reciprocally  receive  a  request  from  the  SWPREOC  Director  of  Operations  about  the  need  for  determining  transportation  routes  from  the  BCeMap  /  MASAS  / 

(simulated  by  interior  BC  down  into  the  USA  via  Osoyoos  (Flighway  97),  through  to  the  coast  (via  Flighways,  20,  2  or  190)  and  back  into  Canada  via  the  15  MASAS  Viewer 
PNNL  Labs)  highway,  this  is  being  looked  at  due  to  rock  fall  blockages  in  the  Fraser  Valley  canyon. 

The  Director  Ops  will  request  information  on  the  state  of  the  highways  in  the  immediate  vicinity  of  Seattle  (15, 1405  and  190)  and  Seattle  will 
put  up  some  pictures  from  SAMapper  (a  situational  awareness  tool)  showing  the  state  of  one  of  he  highways  (e.g.  major  accident, 
congestion  or  bridge  failure,  the  message  can  be  pushed  through  to  BCeMap  or  MASAS  view)  and  can  give  a  general  overview  of  the  state  of 
the  traffic  in  the  area. 

The  DirectorOps  will  ask  if  they  have  any  information  for  the  north,  this  is  nottheirjurisdiction  therefore  they  recommend  getting  hold  of 

Note:  SWPREOC  =  South  West  Provincial  Emergency  Operations  Centre  (one  of  our  five  Provincial  EOCS) . . .  normally  communications  with 
the  USA  has  to  go  up  the  ladder  (provincial  and  federal  but  we  are  assuming  in  the  scenario  that  that  has  been  done  and  local  level 
communications  has  been  approved  for  situation  reports  and  investigation  of  transportations  routes  via  the  US) . 


City  of  Vancouver 

City  of  Vancouver  EOC  members 

ETEam  / 

EOC/311 

reviewing  call  centre  reports  and 
creating  incidents  as  needed  from 
those  reports.  The  significant  one  again 
being  the  reports  relating  to  the 

Georgia  Viaduct  collapse.  The  Eteam 
incidents  should  push  across  to 

BCeMap  (to  be  viewed  in  the  11am 
session). 

BCeMap 
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Earthquake  +  11:00  SWPREOC  /  11:00  -  The  SWPREOC  receives  a  situation  report  from  the  City  of  Vancouver  Emergency  Operations  Centre  centered  around  the  collapse  of  Ushahidi  /  Eteam  / 

28  hours  CoV  EOC  the  Georgia  Viaduct,  damaged  through  the  initial  earthquake  and  subsequently  weakened  by  further  aftershocks.  As  a  result  the  City  of  BCeMap 

Vancouver  is  having  difficulty  getting  resources  into  downtown  core  for  debris  removal  and  are  asking  the  SWPREOC  for  assistance.  The 
dialogue  can  evolve  to  the  possibility  of  using  a  Barge  to  get  some  cranes  into  false  creek  to  help  with  debris  removal,  talk  about  the  need 
to  get  an  engineer  down  there  to  determine  whether  the  foreshore  and  area  around  the  plaza  of  nations  is  of  sufficient  grade  and  the 
cranes  can  get  under  the  pieces  of  viaduct  still  standing.  Use  of  pictures  gathered  from  citizens  using  Ushahidi  to  view  the  extent  of  the 
damage  to  the  Viaduct. 


ll:30-The  SWPREOC  Director  of  Operations  receives  a  situation  report  from  Washington  EMD  based  on  information  captured  in  MASAS/  BCeMap/ 

MyStateUSA  and  pushed  to  our  tools  via  IPAWS  <>  MASAS  <>  BCeMap  around  the  state  of  the  highways  south  of  the  border,  especially  the  IPAWS  /  MyStateUSA 

viability  of  Highways  2,  20or  I90for  moving  Canadian  resources  from  the  interior  BC  down  from  Osoyoos  through  to  Vancouver  through  the 
state  around  or  through  the  National  Parks/forests  around  mount  baker.  The  reports  include  details  on  a  chemical  spill  and  bridge  collapse 
on  the  15  near  Blaine  as  captured  in  MyStateUSA  (and  hopefully  pushed  via  IPAWS  to  BCeMap).  This  means  that  one  of  the  other  border 
crossings  would  have  to  be  used  (e.g.  Sumas  crossing).  There  could  also  be  some  dialogue  around  investigation  of  the  possibility  of  using 
rail.  The  SWPREOC  would  then  commit  to  informing  other  organisations  (BCHydro,  EMS  etc.)  with  mutual  aid  agreements  about  the  best 
possible  routes  and  options.  Close  with  a  discussion  about  when  the  next  update  should  be  (can  reference  that  the  systems  will  be  kept  up 
to  date  and  only  if  information  that  cannot  be  puished  out  automatically  will  there  be  a  need  for  a  call). 

1)  "MyState/WA  issues  CAP  message  for  bridge  closure  at  major  border  crossing,  MASAS  displays  on  map  and  does  whatever  actions  are 
appropriate  and  available  for  test 

Bridge  closure  over  Dakota  Creek  on  Highway  5  just  south  of  Blaine  WAS  issued  by  Whatcom  County  in  MyStateUSA  for 
posting  into  CA  IPAWS  COG  (development  3.0  environment). 

2)  MyState/WA  issues  CAP  message  for  road  closure,  MASAS  displays  on  map  and  does  whatever  actions  are  appropriate  and  available  for 
test. 

1 

3)  MyState/WA  issues  CAP  message  for  HazMat  alert  at  previously  closed  border  crossing  to  include  plume  area  (I  know  MyState  does  this 
but  not  sure  if  it  is  in  WA's  system),  MASAS  show  affected  area  on  map.  Hoping  here  we  can  get  in  the  event  location  layer  but  still  need  to 
make  sure  Joey  is  up  to  speed  with  that) 

Sumas  WA  crossing  east  of  Blaine. 

Reciprocally  the  SWPREOC  gives  a  situation  report  around  information  pushed  to  MyStateUSA  via  MASAS  <>  IPAWS  around  the  state  of  the 
highways  north  of  the  border,  most  notably  the  closure  of  the  Massey  tunnel,  severe  congestion  on  the  Alex  Fraser  bridge  as  a  result,  and  an 
industrial  fire  sending  smoke  across  the  highway  99  in  Whiterock  (just  North  of  the  border). 


Earthquake  +  11:30  SWPREOC/ 

30  hours  WA  EMD 
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Afternoon  Session 

Scenario 

Timeline 

Experiment 

Timeline 

Locations 

involved 

CAUSE  Experiment  Script  Execution  -  Afternoon  session 

Technologies  at  play: 

Earthquake  +8 
hours 

Vignette2vl 
(4hrs)  + 
MystateUSAM 

essages  + 
Vignette2vl 
step  20  (8hrs) 

2.30  pm 

SWPREOC  / 
CoR 

Situation:  8  hours  after  the  earthquake  some  information  has  been  gathered  from  BCeMap/MASAS  regarding  the  earthquake  and 
aftershocks,  bridge  sensors  and  ground  shake  monitors,  ground  shake  model  tool,  plus  some  local  data  has  been  collected  and  entered  into 
Emergeo  regarding  local  incidents/events,  e.g.  some  buildings  experiencing  minorto  moderate  damage,  some  fires  caused  by  broken  gas 
mains  and  other  events  (open  to  suggestions  here  this  section  to  be  dealt  with  in  detail  in  the  session  at  3pm:))  Delta  has  reported  that  the 
Massey  Tunnel  has  experienced  some  damage  due  to  liquefaction  and  is  currently  closed.  Unlikely  to  re-open  in  the  next  72  hours. 

In  a  situation  report  and  resource  request  dialogue  between  CoR  EOC  and  the  SWPREOC,  Richmond  CoR  reports  the  sensor  reading  output 
and  the  fact  that  bridge  sensors  are  reading  that  some  bridge  on  ramp  and  off  ramp  sections  may  have  exceeded  the  design  threshold 
during  one  of  the  aftershocks  and  they  are  closed  pending  reports  from  inspectors  sent  to  investigate.  CoR  can  also  report  the  level  of 
shakingfelt  by  people,  and  also  report  the  output  from  theirground  shake  model  tool  in  terms  of  peakground  acceleration  and  modified 
mercali  index. 

BCeMap/MASAS/ 
Emergeo  /  Hazus 

CoR  can  go  through  some  of  the  more  significant  incidents/building  damage/fires  etc.  entered  into  Emergeo,  and  SWPREOC  should  be  able 
to  see  that  on  screen  through  BCeMap  which  should  have  a  feed  from  Emergio  to  allow  that  data  to  be  seen. 

Southwest  PREOCC  can  pull  up  the  Hazus  map  lodged  with  the  Province  for  the  similar  earthquake  scenario  [Note:  this  could  be  done  before 
the  call  through  dialogue  with  SWPREOC  and  Teron  at  the  PECC?],  to  look  at  the  estimated  debris  model  and  how  many  trucks  they  will 
require  overtime  to  clear  the  debris.  SWPREOC  can  make  a  statement  that  Delta  has  reported  that  they  appear  to  have  been  affected  a  little 
more  than  Richmond  since  they  were  closer  to  the  original  earthquake  and  aftershocks,  and  have  experienced  more  road  closures,  so  they 
will  receive  some  preference  in  terms  of  the  early  debris  removal  activities.  Surrey  has  not  reported  yet  so  that  could  change  and  SWPREOC 
will  keep  CoR  up  to  date. 

CoR  can  say  that  their  internet  connectivity  is  somewhat  patchy  because  of  internet  congestion,  they  assume  there  is  some  damage  to  the 
communications  infrastructure  which  is  being  investigated.  Can  they  have  some  back-up  communications  implemented,  The  SWPREOC  can 
state  that  the  AMECom  truck  is  being  deployed  to  the  airport  in  orderto  provide  them  with  additional  communications  support  and  will 
drop  off  a  tactical  microwave  link  kit  and  team  on  the  way  to  the  Airport.  There  can  be  a  discussion  at  this  point  about  the  best  way  to  get  to 

Earthquake  +4 
hours 

Vignette2vl 

(4hrs) 

3.00pm 

CoR 

CoR  -  has  activated  and  staff  are  arriving  after  making  sure  their  families  are  OK.  Arriving  staff  are  being  brought  up  to  speed  with  the 
situation  (gathered  from  BCeMap/MASAS  regarding  the  8.00am  M9.0  earthquake  and  1st  significant  aftershock  (  9am  M7.1)  both  off  the 
coast  of  Oregon,  the  tsunami  alert  for  Zone  E  coastline  (amplitude  of  only  0.5m,  not  a  concern),  the  bridge  sensors  and  ground  shake 
monitors).  Reports  have  been  requested  from  their  engineers  regarding  the  state  of  the  on  and  off  ramps  on  the  East-West  Connector  and 
Annacis  Channel  bridge  and  parts  of  the  bridge  have  been  closed  in  the  mean  time  (other  side  of  Annacis  island  to  the  Alex  Fraser  Bridge). 
Reports  coming  in  regarding  local  fires  and  damaged  buildings,  this  data  enetered  into  Emergeo  online  . .  .a  conversation  could  take  place 
here  with  CoR  decision  makers  by  phone  who  may  be  remote,  and  logging  onto  Emergeo  from  outside  of  Richmond  to  see  what  is  going  on 
and  actions  that  need  to  be  taken. 

BCeMap/MASAS/ 

Emergeo 

Before  the 
Earthquake 

3.30pm 

CoR  +  NRCan 

(at  CoR)  + 
EMBC 

Victoria  (on 
the  phone) 

Planning  session  between  NRCan  and  CoR  regarding  the  estimation  of  debris  removal  from  Richmond  under  the  scenario  of  a  Casacadian 
Subduction  zone  M9.0  earthquake.  There  can  be  a  dialogue  between  Murray/Nicky  and  Amy  regarding  the  latest  updates  to  the  data  in  the 
Hazus  tool  (e.g.  better  extracts  of  asset  data  from  various  sources,  and  soil  liquefaction  maps  and  and  refinements  done  to  the  scenarios  e.g. 
better  models  for  subduction  zone  type  quake.)  the  discussion  can  include  the  need  to  add  and  refine  the  data  with  more  information  from 
their  local  systems  and  then  the  models  will  output  better  data.  The  demo  can  then  move  onto  selection  of  the  model  and  execution  of  the 
model  analysis  and  discussion  around  what  the  debris  outputs  mean  -  classification  of  the  different  types  of  debris  and  the  ability  to  plan 
the  removal  and  disposal  by  truck,  and  how  many  trucks  based  on  the  size  of  trucks.  The  discussion  should  include  confirmation  by  Teron 
that  the  latest  version  can  be  lodged  with  the  province  as  a  reference  model  to  be  used  for  cross-jurisdictional  planning  purposes  and  for 
assessment  of  relative  damage  and  prioritisation  between  communities  in  the  event. 

Hazus 

A  fYlnm 

CnR 

Intoruioufc 

Glossary 


NAME 

DEFINITION 

AMECom 

Advanced  Mobile  Emergency  Communications 

AHRA 

All  Hazards  Risk  Approach 

AIMS 

Asset  Inventory  Management  System 

BCERMS 

British  Columbia  Emergency  Response  Management  System 

BCSIMS 

British  Columbia  Smart  Infrastructure  Systems 

CAP 

Common  Alerting  Protocol 

CAP-CP 

Common  Alerting  Protocol  -  Canadian  Profile 

CSS 

Centre  for  Security  Science 

DHS 

(US)  Department  of  Homeland  Security 

DRDC 

Defence  Research  and  Development  Canada 

EOC 

Emergency  Operations  Centre 

EMBC 

Emergency  Management  British  Columbia 

EMIS 

Emergency  Management  Information  Service 

FEMA 

(US)  Federal  Emergency  Management  Agency 
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NAME 

DEFINITION 

ICS 

Incident  Command  System 

IPAWS 

Integrated  Public  Alert  Warning  System 

LRDW 

Land  and  Resource  Data  Warehouse 

MASAS 

Multi-Agency  Situational  Awareness  System 

NIEM 

National  Information  Exchange  Model 

NIT 

(MASAS)  National  Implementation  Team 

NRCan 

National  Resources  Canada 

NWS 

(US)  National  Weather  Service 

OPEN 

Open  Platform  for  Emergency  Networks 

PEOC 

(BC)  Provincial  Emergency  Operations  Centre 

PNNL 

Pacific  Northwest  National  Laboratory 

REOC 

(BC)  Regional  Emergency  Operations  Centre 

SFU 

Simon  Fraser  University 

SOREM 

(CA)  Senior  Officials  Responsible  for  Emergency  Management 

TRIM 

Terrain  Resources  Inventory  Mapping 
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NAME 

DEFINITION 

UBC 

University  of  British  Columbia 

UICDS 

Unified  Incident  Command  and  Decision  Support 

USGS 

US  Geological  Survey 

WMS 

Web  Mapping  Service 
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